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I.  INTRODUCTION 


A.  WHY  CHOOSE  WINDOWS  CE  ? 

Windows  CE  is  an  embedded  operating  system  sold  by  Microsoft  and  customized 

by  manufacturers  to  fit  the  needs  of  their  consumers.  It  is  a  versatile  operating  system, 
and  it  has  been  used  in  many  devices  from  industrial  controllers  to  personal  digital 
assistants.  Windows  CE  is  even  used  in  cell  phones  and  television  set-top  boxes.  With 
all  the  flexibility  it  has  to  offer,  not  to  mention  its  compatibility  with  Windows-based 
desktop  computers,  Windows  CE  is  a  good  choice  for  many  tasks  commonly  performed 
in  government  and  military  organizations. 

On  the  other  hand,  with  Palm  OS  devices  accounting  for  approximately  sixty 
percent  of  the  sales  of  personal  assistant  type  devices,  one  might  wonder  why  Windows 
CE  was  chosen  as  the  focus  of  this  study.  Pocket  PCs,  running  a  version  of  the 
Windows  CE  operating  system,  offer  color  display  screens,  have  faster  StrongARM 
processors,  and  present  a  familiar  Microsoft  Windows  style  interface.  They  are  powered 
by  rechargeable  lithium  ion  batteries,  rather  than  the  AAA  batteries  found  in  most  Palm 
OS  devices.  The  Windows  CE  strategy  is  to  offer  a  multifaceted  array  of  services,  rather 
than  simply  provide  basic  functionality  such  as  a  calendar  or  task  manager. 

With  Windows  CE,  a  user  can  work  with  Microsoft  Word  and  Excel  documents, 
listen  to  MP3s,  and  read  digital  books.  However,  the  Windows  CE  operating  system  was 
not  designed  with  security  in  mind.  Due  to  the  unique  constraints  and  challenges 
presented  by  the  hardware  of  most  embedded  devices,  the  foremost  design  objectives 
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were  a  small  memory  footprint  and  enhanced  system  performance.  As  with  many  things 
in  life,  compromises  must  be  made  between  security  and  performance.  The  designers  of 
Windows  CE  heavily  favored  performance  over  security,  but  it  is  not  too  late  to  take  a 
look  back  at  the  system  and  determine  how  its  self-protection  might  be  improved. 

B.  OBJECTIVES 

This  thesis  will  explore  the  organization  of  Microsoft  Windows  CE  3.0.  The 
operating  system  components  are  examined  in  detail,  while  keeping  security  issues  in 
mind.  Penetration  testing  conducted  upon  Windows  CE  will  be  discussed.  Obvious 
security  weaknesses  in  the  operating  system  will  be  addressed,  and  suggestions  for 
improvements  will  be  made. 

With  the  advantages  of  a  security  enhanced  operating  system,  hand-held  devices 
could  be  used  in  more  demanding  environments,  such  as  onboard  a  Naval  vessel.  The 
aim  of  this  thesis  is  to  take  a  first  look  at  methods  for  improving  the  self-protection  of 
Windows  CE.  A  more  robust  operating  system  could  be  utilized  confidently  in  many 
governmental  tasks  requiring  the  use  of  hand-held  devices. 

Some  type  of  control  needs  to  exist  on  the  process  of  upgrading  the  operating 
system  or  applications  on  a  Windows  CE  device.  Without  controls,  malicious  software 
might  be  introduced  or  the  system  itself  might  be  corrupted.  Rather  than  allowing 
anyone  to  modify  system  critical  software,  some  restrictions  should  exist.  Trusted 
subjects  would  be  allowed  to  upgrade  the  system  or  add  new  applications  dynamically, 
providing  new  features  without  compromising  the  device’s  usability.  The  Windows  CE 
operating  system  is  used  for  embedded  systems,  possibly  safety  critical,  in  which  its  self¬ 
protection  may  be  important. 
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C.  THESIS  ORGANIZATION 

This  thesis  consists  of  five  chapters,  and  two  appendices.  Chapter  I  introduces  the 
topic,  and  provides  some  motivation  for  the  study.  Chapter  II  discusses  important 
concepts  related  to  the  redesign  of  operating  systems  for  security,  and  explores  the 
implementation  of  security  in  a  few  modem  operating  systems.  Chapter  HI  describes  the 
security  mechanisms  that  are  currently  present  in  Windows  CE.  Chapter  IV  explains  the 
Flaw  Hypothesis  Method.  It  also  describes  the  penetration  testing  performed  upon 
Windows  CE,  and  the  lab  configuration  required  to  support  the  tests.  Chapter  V 
examines  the  organization  of  the  Windows  CE  operating  system,  while  focusing  on  the 
I/O  and  communication  modules.  Recommendations  are  made  for  improving  the  self¬ 
protection  of  the  system,  and  suggestions  for  future  work  are  proposed.  Appendix  A 
describes  Platform  Builder  and  other  Windows  CE  development  software,  as  well  as  the 
CEPC  reference  platform.  Appendix  B  outlines  a  selection  of  software  analysis  tools  that 
could  be  used  in  analyzing  the  Windows  CE  source  code. 
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H.  OVERVIEW  OF  SECURE  OPERATING  SYSTEMS 


A.  INFORMATION  PROTECTION 

Computers  are  a  part  of  our  everyday  life,  and  they  are  used  in  many  ways  that 
require  some  level  of  information  protection.  Airline  reservation  systems,  e-commerce 
customer  records,  credit  bureau  databases,  law  enforcement  information  systems,  and 
hospital  records  are  all  examples  of  information  stored  on  computers  that  should  be 
protected.  Computer  mechanisms  can  be  used  to  enforce  an  appropriate  security  policy 
that  safeguards  the  sensitive  information.  The  term  security  is  used  to  denote  the 
mechanisms  and  techniques  that  control  who  may  use  or  modify  a  computer  or  the 
information  stored  on  it. 

In  order  to  avoid  known  design  problems,  it  is  necessary  to  review  the  historical 
approaches  to  enhancing  the  security  of  an  existing  operating  system.  We  know  that  a 
secure  system  should  implement  the  Reference  Monitor  Concept  [AND72],  so  that  the 
system  is  self-protecting,  always  invoked,  and  capable  of  being  analyzed.  In  this  context, 
security  refers  to  the  mechanisms  and  techniques  that  control  who  may  use  or  modify  the 
computer  or  its  information. 

A  potential  security  violation  is  the  unauthorized  release  of  information.  This 
includes  traffic  analysis,  in  which  an  intruder  observes  the  patterns  of  information  use 
and  infers  some  content  from  those  patterns.  It  also  includes  the  release  of  sensitive  data 
or  programs. 
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The  unauthorized  modification  of  information  is  another  potential  security 
violation.  An  intruder  might  be  able  to  change  some  vital  stored  information,  possibly 
without  even  seeing  it. 

Denial  of  computer  and  network  services  to  authorized  users  is  also  a  potential 
problem.  The  system  could  be  flooded  with  specific  requests,  so  that  it  is  unable  to 
respond,  or  the  system  could  be  made  unresponsive  in  general.  A  simple  power  outage 
could  also  cause  a  denial  of  service. 

In  the  above  cases,  unauthorized  means  that  the  action  is  happening  without  the 
permission  of  the  person  controlling  the  information,  and  possibly  outside  the  constraints 
imposed  by  the  system  itself.  Some  techniques  commonly  used  to  prevent  security 
violations  are  labeling  files  with  lists  of  authorized  users,  verifying  a  user’s  identity  by  a 
password,  shielding  the  computer  to  prevent  the  interception  and  interpretation  of 
electromagnetic  radiation,  locking  the  room  containing  the  computer,  controlling  who  is 
allowed  to  modify  the  computer  system’s  hardware  and  software,  and  certifying  that  the 
hardware  and  software  are  actually  implemented  as  intended. 

There  are  eight  well-known  design  principles  that  apply  to  security  protection 
mechanisms  [SAL75].  These  principles  are  economy  of  mechanism,  fail-safe  defaults, 
complete  mediation,  open  design,  separation  of  privilege,  least  privilege,  least  common 
mechanism,  and  psychological  acceptability. 

Applying  economy  of  mechanism  means  that  the  system  design  will  be  kept  as 
small  and  simple  as  possible.  A  small  system  is  easier  to  verify  that  it  works  according  to 
the  specifications.  A  simple,  straightforward  system  lends  itself  to  a  thorough 
examination  of  its  correctness. 
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Fail-safe  defaults  in  a  system  ensure  that  the  default  action  is  to  refuse  permission 
and  deny  access.  Thus,  even  if  the  system  defaults  are  used,  the  system  is  still  safe  from 
unauthorized  access.  A  default  to  allow  access  might  go  unnoticed  until  it  was  used  by 
an  intruder  to  penetrate  the  system.  But,  a  default  set  to  deny  access  would  be  noticed  as 
soon  as  an  authorized  user  tried  to  legitimately  access  the  information.  Specific 
permissions  could  be  provided  to  authorized  users  to  allow  their  tasks  to  be  performed. 

To  have  a  secure  system,  every  access  to  every  object  must  be  checked  for 
authority.  In  other  words,  we  need  complete  mediation  between  subjects  such  as 
processes,  and  objects  like  files  or  resources.  If  an  object  could  be  accessed  without  any 
checks,  the  system  security  would  be  bypassed  as  if  it  didn’t  even  exist.  Access  control 
must  be  present  system-wide,  not  just  in  a  particular  system  component. 

A  system  should  not  rely  on  the  secrecy  of  its  design  for  its  security.  An  open 
design  allows  many  people  to  examine  the  system  for  flaws  or  inconsistencies.  As  a 
result,  the  system  can  be  made  stronger.  This  is  much  better  than  just  ignoring  system 
weaknesses  in  the  hope  that  no  one  will  ever  find  them  out.  The  security  mechanisms 
should  not  rely  on  the  ignorance  of  potential  attackers  to  offer  protection. 

The  design  principle  of  separation  of  privilege  guards  against  a  single  point  of 
unauthorized  access.  In  order  to  access  an  object,  more  than  one  condition  must  be  met 
before  access  is  allowed.  For  example,  it  would  be  like  having  two  keys  owned  by  two 
separate  people  to  open  one  protected  safe  with  the  treasure  inside.  The  two  people  must 
cooperate  to  open  the  safe,  and  if  one  person  loses  his  key,  the  safe’s  contents  are  not 
compromised. 
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In  order  to  limit  the  damage  caused  by  an  accident  or  error,  every  program  and 
every  user  of  the  system  should  operate  using  the  least  set  of  privileges  needed  to 
complete  the  job.  This  is  known  as  the  design  principle  of  least  privilege. 

Least  common  mechanism  limits  the  mechanisms  that  are  common  to  more  than 
one  user  and  depended  upon  by  all  users.  Each  shared  mechanism  represents  a  channel 
between  users  and  must  be  designed  very  carefully  to  avoid  compromising  security,  often 
unintentionally. 

The  final  design  principle  is  psychological  acceptability.  No  matter  how  great  the 
system  is,  people  will  not  use  it  if  it  is  strange,  confusing,  or  even  ugly.  The  ways 
available  to  interact  with  the  system  should  match  the  user’s  ideas  of  how  it  should  work. 
The  system  should  be  intuitive,  and  forgiving  of  unexpected  user  input.  The  system 
needs  to  match  its  representation  of  security  features  to  what  the  user  believes  is  needed. 
This  mapping  will  minimize  user  errors  and  frustration. 

The  framework  for  a  secure  system  can  be  built  by  using  these  design  principles. 
This  thesis  investigates  how  these  principles  apply  to  a  redesign  of  the  CE  operating 
system,  and  the  CE  file  system,  serial  I/O,  and  synchronization  mechanisms  in  particular. 
B.  THE  CONCEPT  OF  A  TRUSTED  COMPUTING  BASE 

The  Anderson  Report  [AND72]  introduced  the  idea  of  a  reference  monitor.  The 
reference  monitor  is  responsible  for  system  security  by  enforcing  authorized  access 
relationships  between  subjects  and  objects  within  the  system.  Subjects  are  active  entities 
such  as  processes  or  threads.  Objects  are  passive  entities  like  files  or  database  records. 
An  implementation  of  the  reference  monitor  concept  is  called  a  reference  validation 
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mechanism.  The  reference  validation  mechanism  must  be  tamper  proof,  always  invoked, 
and  small  enough  in  size  to  be  analyzed  and  tested  to  ensure  its  completeness. 

A  security  kernel  exists  in  computer  systems  that  are  designed  and  implemented 
strictly  according  to  the  reference  validation  mechanism  requirements.  Systems  with  the 
Microsoft  Windows  CE  operating  system  do  not  have  a  security  kernel.  Most  systems, 
including  those  running  Windows  CE,  implement  a  reference  validation  mechanism  as 
part  of  a  general-purpose  mechanism  whose  size  and  complexity  make  it  very  hard  to 
analyze  and  test  for  assurance.  Therefore,  most  security  mechanisms  present  are  just 
stuffed  into  various  locations  in  the  operating  system,  rather  than  being  organized  and 
modular.  The  TCSEC  also  describes  the  notion  of  a  Trusted  Computing  Base,  or  TCB,  to 
apply  to  the  majority  of  computer  systems,  which  do  not  have  security  kernels. 

A  TCB  is  defined  as  the  part  of  a  system  which  contains  all  the  elements  of  the 
system  that  are  responsible  for  supporting  and  enforcing  security  policy.  According  to 
this  definition,  non-security  related  mechanisms  can  reside  within  the  TCB.  However,  all 
security  critical  mechanisms  must  be  contained  inside  the  TCB.  When  the  TCB  contains 
non-security  mechanisms,  it  is  generally  accepted  that  such  a  system  does  not  meet  the 
common  standards  for  high  assurance. 

To  achieve  controlled  access  protection  of  a  system,  the  TCB  enforces  isolation  of 
security  related  objects.  The  TCB  must  ensure  that  reusable  objects  do  not  contain 
residual  data  when  they  are  allocated.  The  TCB  also  maintains  audit  information  on  the 
use  of  identification  and  authentication  mechanisms,  object  access,  object  deletion,  and 
the  activities  of  users,  system  administrators,  and  security  administrators.  The  TCB  must 
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isolate  protected  resources  to  ensure  that  access  controls  and  audit  requirements  are 
enforced. 

C.  HISTORIC  EXAMPLES 

In  any  engineering  task,  it  is  always  good  to  take  a  look  back  at  previous  related 
designs  so  that  mistakes  are  not  repeated.  Good  design  approaches  can  be  reused  to 
jump-start  project  development,  and  major  pitfalls  can  be  avoided  by  noticing  those  that 
have  trapped  people  in  the  past.  Two  major  security  redesign  projects  of  the  1970’s  were 
the  Multics  kernel  redesign,  and  the  KVM/370  redesign. 

1.  Multics  Kernel  Redesign 

In  the  paper  “The  Multics  Kernel  Design  Project”  [SCH77],  Michael  Schroeder, 
David  Clark,  and  Jerome  Saltzer  discussed  the  work  that  was  done  to  make  the  Multics 
kernel  more  secure.  Multics  stands  for  Multiplexed  Information  and  Computing  Service. 
It  was  a  mainframe  timesharing  operating  system  that  was  developed  in  1965. 
Originally,  Multics  was  a  joint  research  project  by  MIT’s  Project  MAC,  Bell  Telephone 
Laboratories,  and  General  Electric  Company's  Large  Computer  Products  Division.  The 
system  evolved  into  a  commercial  operating  system  that  was  sold  by  Honeywell.  Multics 
was  used  in  many  sectors  of  the  population,  from  education  to  government  and  industry. 

The  main  objectives  of  the  design  project  were  to  demonstrate  security  for  a  large, 
working  operating  system,  and  to  show  that  Multics  could  enforce  a  security  policy.  A 
few  troubling  problems  were  encountered  along  the  way.  Today,  decades  later,  we  still 
have  the  problem  of  just  how  to  evaluate  and  understand  large  amounts  of  source  code 
that  were  written  by  many  people  over  time.  Another  problem  was  how  to  express  all  of 
the  security  mechanisms  in  a  simple,  verifiable  model.  Then,  as  now,  ad  hoc  security 
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mechanisms  existed  outside  the  operating  system,  and  were  hard  to  incorporate  into  the 
implementation  of  a  security  kernel. 

People  agreed  that  some  type  of  integrity  audit  was  essential  before  the  Multics 
operating  system  could  be  used  to  protect  sensitive  information,  such  as  military  data 
existing  at  different  security  classification  levels.  To  make  Multics  more  secure,  the 
kernel  had  to  be  simplified  so  that  an  evaluator  could  understand  it.  By  simplifying  the 
kernel,  the  risk  of  overlooking  a  threat  to  system  security  was  reduced.  A  second  subgoal 
of  the  project  was  to  provide  a  set  of  security  functions  that  could  be  described  by  a 
simple  formal  model.  By  describing  the  security  functions  in  a  formal  model,  their 
correctness  could  be  verified  more  rigorously  than  an  informal  review  would  permit. 
This  formal  model  provided  more  assurance  that  the  security  functions  were  behaving  in 
accordance  to  the  defined  security  policy.  For  more  details  on  the  model  used,  see  the 
paper  “The  Multics  Kernel  Design  Project”  [SCH77]. 

The  Multics  kernel  design  project  explored  some  major  issues,  such  as  the 
possibility  of  being  evaluatable,  the  actual  usefulness  of  the  formal  model,  and  the  impact 
of  the  security  redesign  on  overall  system  performance.  Some  questioned  whether  it  was 
even  possible  to  evaluate  a  system  of  such  a  large  size.  There  was  a  concern  that  the  cost 
of  using  a  formal  model  might  outweigh  the  model’s  usefulness  to  the  project  as  a  whole. 
Finally,  system  performance  was  also  a  design  compromise  between  security 
mechanisms  and  responsiveness.  There  would  not  be  a  large  consumer  market  for  a 
system  that  was  very  secure  and  yet  very  slow. 

Instead  of  developing  their  own  formal  model,  the  Multics  team  used  the  MITRE 

model  of  sensitivity  levels  and  compartments  [BEL73].  This  model  constrained  the  flow 
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of  information  by  preventing  information  to  be  written  down  from  a  higher  security  level 
to  a  lower  level.  The  model  also  prohibited  reading  information  at  a  higher  security  level 
than  the  current  security  level.  AIM,  the  Access  Isolation  Mechanism,  was  a  set  of 
security  features  that  was  added  to  Multics.  AIM  implemented  the  labeling  of  all 
information,  and  enforced  security  checks  at  all  points  where  information  could  cross 
level  or  compartment  boundaries. 

At  that  point  in  the  Multics  design  project,  several  goals  were  pursued.  Work  was 
done  to  add  AIM  to  Multics,  and  to  develop  prototypes  to  implement  security  functions 
in  better,  more  efficient  ways.  More  detailed  formal  system  specifications  were 
developed,  and  then  verified.  The  central  supervisor  was  reimplemented  to  allow  more 
verification. 

The  new,  easier-to-review  version  of  Multics  with  AIM  was  named 
Kemel/Multics.  One  of  the  difficult  parts  of  the  project  was  to  certify  that 
Kemel/Multics  complied  with  the  documented  specifications.  In  order  to  do  that, 
program  verification  tools  were  used,  the  source  code  was  audited,  user  testing  and  error 
reporting  were  conducted,  and  penetration  testing  of  the  system  was  performed.  All  of 
these  methods  were  employed  to  verify  the  integrity  of  Kemel/Multics. 

Three  major  redesign  proposals  were  made.  The  first  was  to  remove  protected 
supervisor  functions  from  the  kernel  if  the  functions  did  not  absolutely  need  to  be  there. 
The  idea  was  to  put  only  the  minimal  necessary  functions  in  the  protected  kernel. 
However,  moving  some  of  the  functions  out  of  the  kernel  had  an  adverse  effect  on  overall 
system  performance.  The  second  proposal  was  to  implement  the  protected  functions  by 
using  the  natural  separation  given  by  independent  processes  operating  in  distinct  address 
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spaces.  The  third  proposal  was  to  use  systematic  program  structuring  techniques  for  the 
kernel.  Ideas  from  all  three  of  these  proposals  were  used. 

Type  extension  is  a  method  that  makes  all  modules  into  object  managers, 
categorizes  the  ways  one  module  can  depend  on  another,  and  organizes  modules  into  a 
loop-free  dependency  structure.  This  method  was  used  to  implement  structured 
programming  in  the  kernel.  Each  module  was  an  object  manager,  so  the  interface  to  each 
module  defined  all  the  operations  on  the  object  type  managed  by  that  module.  Some 
examples  of  object  types  used  in  the  Multics  kernel  design  are  disk  records,  core  blocks, 
core  segments,  and  page  frames.  Dependencies  between  modules  can  be  explicit,  caused 
by  procedure  calls  or  interprocess  messages  that  wait  for  replies.  Implicit  dependencies 
are  those  caused  by  direct  sharing  of  writable  data  among  modules.  In  the  Multics 
redesign,  it  was  necessary  to  remove  the  dependency  loops  so  that  the  correctness  of  each 
module  could  be  established  independently. 

In  order  to  identify  all  the  dependency  loops  between  modules,  the  dependencies 
were  placed  into  one  of  five  categories.  These  categories  were  component  dependencies, 
map  dependencies,  program  storage  dependencies,  address  space  dependencies,  and 
interpreter  dependencies.  Component  dependencies  exist  when  a  module’s  objects  are 
composed  of  another  module’s  objects.  Map  dependencies  occur  when  a  module 
depends  on  the  managers  that  provide  the  objects  in  which  the  map  of  object  names  to 
component  names  is  stored.  Program  storage  dependencies  are  related  to  where  a 
module’s  algorithms  and  data  are  temporarily  stored.  An  address  space  dependency 
means  that  a  module  executes  in  an  object’s  address  space,  which  depends  on  the 
module’s  managers.  For  interpreter  dependencies,  a  module  depends  on  the  module  that 
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implements  its  interpreter,  or  the  virtual  processor  on  which  it  executes.  By  identifying 
module  dependencies,  the  Multics  redesign  effort  allowed  their  elimination  to  produce  a 
loop-free  collection  of  object  managers. 

So,  it  was  possible  to  implement  the  complete  Multics  kernel  functionality 
through  a  loop-free  structure  of  object  managers  by  using  the  rationale  of  type  extension 
and  the  five  kinds  of  dependencies.  By  doing  this,  it  became  feasible  for  a  single 
evaluator  to  examine  the  kernel  and  be  assured  of  its  correctness.  Kemel/Multics  was 
developed  to  incorporate  the  necessary  security  mechanisms  and  make  the  kernel  easier 
to  review.  The  MITRE  formal  security  model  of  sensitivity  labels  and  compartments  was 
applied  to  describe  Multics  system  security  functions  in  a  clear  and  consistent  way.  The 
Multics  kernel  redesign  proved  that  an  existing  operating  system  could  be  re-engineered 
to  enhance  its  security. 

2.  VM/370  Redesign 

The  paper  “A  Security  Retrofit  of  VM/370”  explains  the  design  work  that  was 
done  to  add  a  feasible,  formally  verified  security  kernel  to  the  existing  VM/370  operating 
system  [GOL79].  A  goal  for  the  security  kernel  was  to  allow  verification  with  respect  to 
the  security  policy.  It  had  a  tolerable  effect  on  overall  performance,  and  required 
minimal  replacement  of  existing  code.  The  security  kernel  was  also  designed  to  be 
backwards  compatible  with  existing  applications. 

The  general  redesign  strategy  was  to  partition  the  VM/370  control  program  into 
security-relevant  and  non-security-relevant  modules.  Modules  that  were  security  relevant 
were  those  that  executed  privileged  instructions  or  accessed  global  system  data.  The  plan 
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was  to  use  encapsulation  of  multiple,  individual  copies  of  an  operating  system  under  a 
virtual  machine  monitor  (VMM)  system  to  provide  a  secure  OS. 

The  new,  security  enhanced  OS  was  called  KVM/370.  Its  system  architecture  had 
four  main  components.  The  kernel  and  verified  trusted  processes  operated  in  the 
supervisor  ring,  separated  from  the  rest  of  the  system.  Audited  semi-trusted  processes 
were  used  to  access  virtual  addresses.  A  Non-kemel  Control  Program  (NKCP)  existed 
for  each  security  level,  to  act  as  an  interface  to  the  user  Virtual  Machines  (VMs).  The 
last  component  was  user  Virtual  Machines  that  were  each  controlled  by  the  appropriate 
NKCP  for  the  appropriate  security  level. 

Some  design  tradeoffs  were  considered  for  the  resource  scheduling  and 
management.  They  could  either  be  done  in  a  system  global  manner,  or  on  a  NKCP  local 
basis.  If  implemented  globally,  the  size  of  the  kernel  and  trusted  processes  would 
increase.  There  would  be  a  complicated  interface  between  the  NKCPs  and  the  global 
processes.  Verification  would  be  more  difficult  and  expensive,  and  it  would  be  harder  to 
modify  the  system.  However,  performance  would  improve  with  this  approach.  By  using 
a  NKCP  local  basis  for  resource  scheduling,  most  resource  management  would  be  done 
by  the  NKCPs.  That  would  simplify  the  system  design,  implementation,  verification,  and 
interfaces.  The  problem  with  NKCP  local  approach  is  that  system  performance  would  be 
adversely  affected.  So,  it  was  decided  to  use  a  mixture  of  the  two  approaches  in  order  to 
preserve  adaptability  and  ease  of  verification. 

As  part  of  the  system  redesign,  the  kernel  and  trusted  processes  were  the  only 
parts  of  the  KVM/370  whose  formal  specifications  were  formally  verified.  The  formal 
proof  of  correctness  required  that  the  kernel  and  trusted  processes  enforced  the  security 
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policy.  The  proof  also  required  a  demonstration  to  show  that  there  were  no  unauthorized 
signaling  capabilities,  or  covert  channels,  within  the  semi-trusted  processes. 

In  general,  the  KVM/370  redesign  was  based  on  the  principles  of  least  privilege 
and  least  common  mechanism.  These  two  principles  can  also  be  applied  to  a  redesign  of 
the  Windows  CE  operating  system.  When  possible,  security  related  modules  should  be 
separated  out  from  the  rest  of  the  system.  Overall  system  performance  should  be 
considered,  and  formal  verification  should  be  used  if  needed. 

D.  SECURITY  IN  MODERN  OPERATING  SYSTEMS 

Modem  desktop  operating  systems  such  as  Windows  NT  or  Linux  do  not 
incorporate  a  security  kernel.  However,  they  do  offer  various  security  services  and  forms 
of  access  control.  Personal  Digital  Assistant  (or  PDA)  operating  systems  such  as 
Windows  CE  or  Palm  OS  have  rudimentary  security  features  and  limited  self-protection 
of  the  operating  system  itself.  As  PDA  devices  are  becoming  more  connected  to 
networks  and  through  the  use  of  wireless  technology,  the  security  of  such  devices 
becomes  a  more  important  issue.  It  is  interesting  to  take  a  look  at  how  the  different 
operating  systems  compare  to  the  design  principles  outlined  in  the  paper  by  Saltzer  and 
Schroeder. 

1.  Windows  NT  Security 

There  is  a  thorough  explanation  of  Windows  NT  security  features  in  the  book 
Inside  Windows  NT,  by  David  Solomon  [SOL98].  Economy  of  mechanism  is  proposed 
in  the  design  of  Windows  NT,  but  it  is  debatable  whether  it  can  be  applied  to  an  operating 
system  of  such  a  large  size.  As  for  fail-safe  defaults,  NT  first  checks  if  the  desired  access 
to  an  object  is  allowed.  The  default  is  to  deny  access,  which  is  safe  in  any  case. 
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Mediation  is  accomplished  through  the  use  of  Access  Control  Lists  (ACL).  The  system 
design  is  partially  open  due  to  the  books  written  about  how  NT  behaves,  even  though  the 
source  code  is  not  available.  Separation  of  privilege  is  accomplished  through  the  use  of 
different  user  roles,  such  as  administrator,  power  user,  user,  and  guest.  The  principle  of 
least  privilege  is  met  by  providing  various  access  modes  such  as  read,  write,  execute,  and 
append.  Least  common  mechanism  is  observed  through  the  use  of  various  modules  for 
different  tasks.  The  security  reference  monitor  (SRM),  kernel,  local  security  authority 
(LSA),  and  security  accounts  manager  (SAM)  each  provide  needed  features  in  a  modular 
way.  Mechanisms  that  must  be  shared  are  logged.  As  for  using  an  isolated  virtual 
machine,  a  real  CPU  abstraction  called  the  hardware  abstraction  layer  (HAL)  with  virtual 
resources  is  provided.  The  authentication  mechanism  is  met  by  the  Windows  logon, 
which  is  flexible  enough  to  incorporate  a  password,  smartcards,  or  biometrics.  For 
shared  information,  NT  uses  an  Access  Control  List  when  opening  objects,  and  a  ticket 
called  a  handle  when  accessing  objects.  Linear  32-bit  addressing  is  used  in  Windows 
NT.  NT  is  not  a  capability  system  and  has  no  tag  bits.  NT  security  is  based  on  ACLs 
and  permissions.  As  for  protection  groups,  NT  uses  system  groups  and  user  groups.  The 
authority  to  change  ACLs  is  given  to  the  owner  and  the  administrator,  as  well  as  anyone 
else  that  the  owner  or  administrator  has  given  permission  to.  NT  only  supports  a 
Discretionary  Access  Control  (DAC)  policy.  There  is  an  ACL  strategy  for  all  objects, 
and  permissions  are  object  dependent.  NT  does  have  protected  subsystems,  such  as  the 
local  security  authentication  server  (LSASS),  but  they  are  not  available  to  users. 

2.  Windows  CE  Security 

The  organization  and  design  objectives  of  Windows  CE  are  discussed  in  the  book 

Inside  Microsoft  Windows  CE,  by  John  Murray  [MUR98].  Details  of  Windows  CE 
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security  features  can  be  found  in  the  Microsoft  technical  article  “Creating  a  Secure 
Windows  CE  Device”  [ALFOO].  Windows  CE  addresses  economy  of  mechanism  by 
keeping  the  OS  size  small,  and  by  introducing  modules  and  components.  Since  memory 
space  in  embedded  devices  is  at  a  premium,  effort  was  taken  to  make  the  OS  as  small  and 
streamlined  as  possible.  Unnecessary  modules  or  components  for  a  specific  device  can 
be  removed,  simplifying  the  design.  Windows  CE  does  not  support  fail-safe  defaults. 
There  is  very  little  security  implemented  in  its  default  configuration.  There  are  no  access 
permissions  associated  with  objects,  no  user  identification  or  authentication,  and  the 
default  is  to  run  all  processes  and  threads  in  kernel  mode  to  enhance  system  performance. 
There  is  a  mechanism  to  certify  code  modules,  but  it  is  turned  off  by  default.  A  unique 
device  identifier  may  be  assigned,  but  One  is  not  given  in  the  default  configuration. 
There  is  no  mediation  at  all,  since  subjects  and  objects  are  not  assigned  access  modes. 
There  is  a  password  for  the  device,  but  the  user  must  first  enable  that  feature.  The  system 
design  is  open  to  certain  manufacturers  who  have  agreements  with  Microsoft.  Otherwise, 
the  design  is  partially  open,  because  its  high  level  structure  is  documented  on  Microsoft’s 
web  sites  and  in  some  books.  Separation  of  privilege,  least  privilege,  and  least  common 
mechanism  do  not  apply,  because  a  complete  set  of  protection  mechanisms  does  not 
exist  in  Windows  CE.  There  is  a  real  CPU  abstraction  called  the  OAL,  or  OEM 
Adaptation  Layer,  between  the  actual  hardware  and  the  operating '  system  itself.  The 
OAL  serves  a  similar  function  to  the  HAL  in  Windows  NT.  As  stated  before,  there  is  no 
intrinsic  authentication  mechanism.  However,  support  does  exist  for  smartcard  readers  to 
be  added  in  later.  As  for  shared  information,  all  processes  share  a  common  memory 
space,  by  default  providing  no  distinction  between  kernel  level  and  user  level  memory. 
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Windows  CE  does  not  use  protection  groups.  The  only  protected  subsystem  is  a  portion 
of  the  operating  system  kernel. 

3.  Palm  OS  Security 

The  Palm  OS  is  described  in  the  book  Palm  Programming:  The  Developer’s 
Guide  [RH098].  The  Palm  OS  provides  for  economy  of  mechanism  in  much  the  same 
way  as  Windows  CE.  The  OS  has  a  small  footprint  that  is  well  suited  for  the  PDA 
devices  it  is  typically  installed  upon.  The  OS  is  divided  into  subsystems  called  managers, 
such  as  the  Memory  Manager  or  the  Database  Manager.  Considering  fail-safe  defaults, 
the  Palm  OS  originally  has  its  password  and  auto-lock  features  turned  off.  The  user  is 
responsible  for  enabling  those  features  and  for  marking  certain  application  data  as 
“private”.  As  with  Windows  CE,  there  is  no  mediation  because  access  modes  are  not 
defined.  User  identification  and  authentication  are  not  implemented.  The  system  design 
is  partially  open,  because  books  and  online  documentation  are  available  that  discuss  the 
high-level  design  and  programming  interface.  Separation  of  privilege,  least  privilege, 
and  least  common  mechanism  are  not  addressed,  due  to  the  lack  of  Palm  OS  security 
mechanisms  in  general.  A  user  authentication  mechanism  is  not  provided.  No 
protections  groups  exist,  and  only  parts  of  the  operating  system  are  protected. 

PDAs  are  used  in  a  radically  different  environment  from  that  of  the  typical 
desktop  PC.  Rather  than  sitting  for  long  periods  at  a  desk,  PDA  users  walk  around,  enter 
short  notes  while  in  the  middle  of  other  tasks,  and  retrieve  PDA  information  as  needed  on 
location.  The  desktop  security  model  might  not  fully  encompass  the  different  ways  that 
PDAs  are  used.  When  considering  Windows  CE  security,  one  should  be  mindful  of  how 
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and  where  the  PDA  devices  are  used,  and  how  its  security  approach  might  differ  from 
that  of  a  desktop  computer. 
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HI.  SECURITY  IN  WINDOWS  CE  DEVICES 


A.  WINDOWS  CE  SOFTWARE  TRUST  APPROACH 

According  to  the  Microsoft  article,  “Creating  a  Secure  Windows  CE  Device” 
[ALFOO],  Windows  CE  3.0  provides  an  integrated  set  of  security  services  with  nine  main 
features.  The  features  include  providing  a  “trusted  environment”  model,  the  Security 
Support  Provider  Interface  (SSPI),  support  for  Windows  NT  LAN  Manager,  support  for 
the  Secure  Sockets  Layer  (SSL),  cryptography,  a  smart  card  infrastructure  that  supports 
the  Microsoft  Cryptographic  API  (CAPI),  a  unique  device  identifier,  a  protected  kernel 
configuration,  and  digital  authentication  in  the  dial-up  boot  loader. 

Two  Windows  CE  API  functions  are  provided  for  Original  Equipment 
Manufacturers,  or  OEMs,  to  implement  in  order  to  create  a  trusted  environment.  Using 
these  functions  can  prevent  unknown  modules  from  being  loaded,  restrict  access  to 
system  APIs,  and  prevent  write  access  to  selected  parts  of  the  system  registry.  As  one 
can  see,  this  definition  of  a  trusted  environment  is  not  quite  the  same  as  having  a  TCB. 

The  first  provided  function  is  OEMCertifyModulelnit.  It  is  called  once  for 
initialization  of  each  RAM  executable  module  to  be  checked.  The  function  returns  either 
true  or  false,  depending  on  the  success  of  the  initialization.  What  this  function  actually 
does  is  determined  by  the  needs  of  the  OEM.  For  example,  it  could  be  setting  up  public 
keys  or  using  the  Loadauth  library  routines  included  with  Platform  Builder. 

The  second  function  is  OEMCertifyModule.  This  function  allows  the  OS  loader 

to  pass  the  module  code,  which  could  be  a  DLL  or  EXE  type  file,  to  the  OEM  for 

verification  that  the  module  is  safe  to  run  on  the  system.  The  return  values  for 
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OEMCertifyModule  are  OEM_CERTDFY_TRUST,  OEM_CERTIFY_RUN,  and 
OEM_CERTIFY_FALSE.  OEM_CERTIFY_TRUST  signifies  that  the  module  code  is 
trusted  to  perform  any  operation.  OEM_CERTIFY_RUN  means  that  the  module  is 
trusted  to  ran,  but  is  restricted  from  making  some  selected  privileged  function  calls. 
OEM_CERTIFY_FALSE  means  that  the  module  is  not  trusted  and  therefore  not  allowed 
to  ran.  To  find  out  the  trust  level  of  a  calling  application,  dynamic-link  libraries  can  use 
the  CeGetCurrentTrast  and  CeGetCallerTrast  functions  in  addition  to  the  OEM  functions. 

It  is  the  responsibility  of  the  OEM  to  perform  the  desired  checks  on  the  code 
module  in  the  OEMCertifyModule  function.  These  checks  could  be  a  cyclic  redundancy 
check  to  verify  integrity  or  a  public  key  certificate  check.  Basically,  this  function  is  only 
as  good  as  the  means  chosen  to  verify  the  code  module,  which  will  vary  from  one  OEM 
to  another.  Some  OEMs  may  choose  not  to  certify  modules  at  all. 

When  a  dynamic-link  library  (or  DLL)  is  loaded  into  the  address  space  of  an 
executable  file  (or  EXE),  the  trust  level  of  the  EXE  process  determines  the  final  access 
level.  For  example,  when  an  EXE  with  the  OEM_CERTIFY_RUN  trust  level  tries  to 
load  a  DLL  that  has  a  higher  trust  level  of  OEM_CERTIFY_TRUST,  the  final  trust  level 
of  the  DLL  is  lowered  to  OEM_CERTIFY_RUN.  If  an  EXE  tries  to  load  a  DLL  with  a 
lower  trust  level  than  its  own,  the  DLL  will  fail  to  load.  If  the  EXE  trust  level  is 
OEM_CERTIFY_FALSE,  the  EXE  will  not  ran.  If  the  DLL  trust  level  is 
OEM_CERTIFYJFALSE,  the  DLL  will  fail  to  load.  The  different  combinations  of  EXE 
and  DLL  trust  levels  are  listed  in  the  following  Table  3.1  [ALFOO]. 
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EXE  Trust 

DLL  Trust 

Final  DLL  Trust 

OEM_CERTTFY_RUN 

OEM_CERTIFY_RUN 

OEM_CERTIFY_RUN 

OEM_CERTIFY_RUN 

OEM_CERTIFY_TRUST 

OEM_CERTIFY_RUN 

OEM_CERTEFY_RUN 

OEM_CERTIFY_FALSE 

DLL  fails  to  load 

OEM_CERTEFY_TRUST 

OEM_CERTIFY_RUN 

DLL  fails  to  load 

OEM_CERTIFY_TRUST 

OEM_CERTEFY_TRUST 

0EM_CERT1FY_TRUST 

OEM_CERTlFY_TRUST 

OEM_CERTIFY_F  ALS  E 

DLL  fails  to  load 

OEM_CERTEFY_FALSE 

RUN,  TRUST,  or  FALSE 

DLL  fails  to  load,  and  EXE 
will  not  run 

Table  3.1  Trust  Level  Combinations 


It  seems  like  it  would  be  a  good  idea  to  use  the  two  provided  security  functions  to 
restrict  unknown  modules  from  running.  However,  in  order  to  support  third  party  drivers, 
the  OEMs  must  digitally  sign  them,  or  have  the  check  in  OEMCertifyModule  always 
return  OEM_CERTIFY_TRUST  for  all  of  the  chosen  drivers  or  the  drivers  will  be 
prevented  from  loading.  This  seems  like  a  point  that  would  deter  the  OEMs  from 
choosing  to  use  the  two  security  functions  in  the  first  place.  The  problem  of  certifying 
modules  that  have  not  yet  been  written  is  one  that  demands  careful  thought.  OEMs  would 
most  likely  want  to  support  as  many  drivers  as  possible,  and  new  drivers  might  not  be 
available  at  the  time  of  the  Windows  CE  device  manufacture.  This  could  potentially 
cause  difficulties  in  implementing  and  using  a  module  certification  scheme  based  upon 
the  functions  OEMCertifyModule  and  OEMModulelnit. 
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Another  point  to  remember  is  that  the  names  of  the  functions 
OEMCertifyModulelnit  and  OEMCertifyModule  are  arbitrary  and  any  names  can  be  used 
as  long  as  the  kernel  pointers  pOEMLoadlnit  and  pOEMLoadModule  in  the  OEMInit 
function  are  initialized  to  the  desired  functions. 

When  a  code  module  has  a  trust  level  of  OEM_CERTIFY_RUN,  it  is  restricted 

from  calling  the  following  API  functions: 

SetlnterruptEvent 

SetSystemMemoryDivision 

CES  etThreadPriority 

ForcePageout 

VirtualCopy 

LockPages 

UnlockPages 

SetProcPermissions 

SetKMode 

ReadProcessMemory 

WriteProcessMemory 

SetCleanRebootFlag 

PowerOffSystem 

DebugActiveProcess 

In  the  CreateProcess  function,  the  debug  flags  DEBUG_ONLY_THIS_PROCESS 

and  DEBUG_PROCESS  are  restricted  as  well.  The  registry  architecture  in  Windows  CE 

3.0  permits  only  code  modules  with  a  level  of  OEM_CERTlFY_TRUST  (which 

Microsoft  calls  trusted  applications)  to  modify  protected  keys  and  values.  The  following 

registry  root  keys  and  their  subkeys  are  protected: 

HKEY_LOCAL_MACHINE\Comm 

HKEY_LOCAL_MACHINE\Drivers 

HKEY_LOCAL_MACHINE\HARDWARE 

HKEY_LOC  AL_M  ACHINE\S  Y  STEM 

HKEY_LOCAL_MACHINE\Init 

HKEY_LOCAL_MACHINE\WDMDrivers 


24 


To  protect  the  registry,  Windows  CE  restricts  some  applications  from  invoking 
certain  registry  function  calls.  Untrusted  applications,  which  are  those  defined  by 
Microsoft  as  not  having  the  trust  level  of  OEM_CERTIFY_TRUST,  receive  the  return 
value  of  ERROR_ACCESS_DENIED  if  they  try  to  use  the  registry  functions 
RegSetValueEx,  RegCreateKeyEx,  RegDeleteKey,  and  RegDeleteValue. 

Everything  else  in  the  registry  is  unprotected.  Microsoft  recommends  that  the 
OEMs  place  all  their  important  registry  information  into  one  of  the  protected  keys.  Code 
modules  with  a  trust  level  of  OEM_CERTIFY_RUN  can  read  all  registry  keys  and 
values.  In  fact,  all  applications  have  read-only  access  to  all  of  the  keys  and  values  in  the 
registry. 

B.  UNIQUE  DEVICE  IDENTIFICATION 

Another  security  service  that  Windows  CE  can  provide  is  unique  device 
identification.  A  DEVICEJD  data  structure  is  provided  for  the  OEM  to  store  a  unique 
identification  number  for  each  device.  The  input/output  control 
IOCTL_HAL_GET_DEVICEID  in  the  OEM  adaptation  layer  (CE’s  version  of  the  HAL, 
Hardware  Abstraction  Layer,  in  Windows  NT)  returns  the  current  DEVICEJD  assigned 
to  the  Windows  CE  device.  Device  identification  could  be  used  for  billing  or  security 
purposes.  If  using  the  device  id  for  security,  care  should  be  taken  that  the  usage  fits  into 
the  overall  security  policy  and  that  the  implementation  is  sound. 

Two  modes  of  operation  exist  for  the  Windows  CE  kernel,  protected  mode  and 
full-kernel  mode.  Protected  kernel  mode  is  available  to  reduce  the  vulnerability  of  the 
memory  storage,  but  using  it  will  cause  overall  system  performance  to  degrade.  The 
default  mode  of  operation  is  full-kernel  mode.  Windows  CE  is  vulnerable  when  using 


25 


full-kernel  mode  while  running  threads,  since  the  security  features  are  bypassed.  In  full- 
kernel  mode,  applications  can  access  any  physical  memory  in  the  system.  This  means 
that  the  system  can  be  exploited  by  malicious  applications  that  scavenge  privileged 
information  or  delete  files.  Running  in  full-kernel  mode  increases  performance  at  the 
cost  of  system  security.  Full-kemel  mode  can  be  disabled  by  setting  the  second  bit  of 
ROMFLAGS  in  the  Config.bib  file  before  building  the  operating  system  image.  By 
disabling  full-kemel  mode,  the  kernel  operates  in  protected  mode,  restricting  the  physical 
memory  access  of  user  level  threads. 

Windows  CE  has  a  dial-up  boot  loader  stored  in  ROM  that  can  be  used  to  upgrade 
the  OS  image  file,  Nk.bin,  using  flash  memory  or  a  remote  server.  To  help  ensure  the 
integrity  of  the  OS  image,  digital  encryption  can  be  used  to  sign  and  verify  image  files. 
The  dial-up  boot  loader  uses  the  Microsoft  Cryptography  Application  Programming 
Interface  (CAPI)  to  authenticate  data  using  the  asymmetric  hashing  algorithm 
CALG_SHA,  which  produces  a  160-bit  hash  value.  The  dial-up  boot  loader  extracts  the  ' 
signatures  from  the  manifest  file  and  verifies  the  authenticity  of  each  OS  image  file.  In 
the  case  of  authentication  failure,  the  download  process  is  halted  and  the  user  is  notified. 
Platform  Builder  3.0  provides  three  tools  for  digital  authentication.  Makekey.exe  creates 
a  public/private  key  pair.  The  program  mksigs.exe  signs  the  OS  image  files.  The 
signatures  can  be  appended  to  the  manifest  file  by  running  th6  addsigs.exe  program. 

C.  APPLICATION  LEVEL  SECURITY  SERVICES 

Windows  CE  also  offers  application  level  security  services  [ALFOO].  These 
services  include  the  Security  Support  Provider  Interface  (SSPI),  Security  Support 
Providers  (SSPs),  Windows  NT  LAN  Manager  Security  Support  Provider,  Secure 
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Sockets  Layer  (SSL),  Microsoft  Cryptography  API  (Crypto  API  or  CAPI), 
Cryptographic  Service  Providers  (CSPs),  and  Smart  Card  Service  Providers  (SCSPs). 

SSPI  resides  in  the  Secure32.dll  module.  It  is  an  API  designed  for  obtaining 
integrated  security  services  for  authentication,  message  integrity,  and  message  privacy. 
SSPI  acts  as  an  abstraction  layer  between  application  level  protocols  and  security 
protocols.  The  Windows  CE  SSPI  provides  access  to  the  DLLs  which  contain  the 
available  authentication  and  cryptographic  libraries.  These  DLLs  are  known  as  Security 
Support  Providers  (SSPs),  or  security  packages.  The  SSPI  allows  the  use  of  one  or  more 
SSPs  by  any  application  that  desires  them.  It  is  also  possible  for  an  OEM  to  write 
customized  security  packages  and  add  them  to  the  registry. 

According  to  the  book  Network  Programming  for  Microsoft  Windows  [JON99], 
Winsock  is  the  preferred  interface  for  accessing  a  variety  of  underlying  network  protocols 
and  is  available  in  varying  forms  on  every  Win32  platform.  Winsock  is  a  network 
programming  interface  and  not  a  protocol.  The  Winsock  interface  inherits  a  great  deal 
from  the  Berkeley  (BSD)  Sockets  implementation  on  UNIX  platforms,  which  is  capable 
of  accessing  multiple  networking  protocols.  Winlnet  operates  at  the  session  layer. 
Winlnet  handles  programming  Windows  Sockets  (Winsock),  TCP/IP,  and  Internet 
protocols. 

» 

Figure  3.1  illustrates  the  relationship  between  the  SSPs,  the  SSPI,  Winsock,  and 
Winlnet. 
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Figure  3.1  Security  Support  Provider  Relationships  [From:  ALFOO] 

Windows  NT  LAN  Manager  Security  Support  Provider  (NTLMSSP)  is  available 
for  use  with  Windows  CE.  In  client-server  applications,  NTLMSSP  can  be  used  by 
Windows  CE  applications  for  user  authentication  to  a  NT  server.  The  client  application 
supplies  the  user  name,  domain  name,  and  password  to  the  NTLMSSP  and  the  server  and 
client  applications  exchange  tokens  to  complete  the  authentication.  This  type  of  client- 
server  exchange  could  take  place  during  an  ActiveSync  session. 

Windows  CE,  unlike  Windows  NT,  does  not  support  impersonation.  This  means 
that  Windows  CE  does  not  allow  an  object  to  acquire  the  security  credentials  of  an 
authenticated  user  or  client.  Authentication  under  Windows  CE  is  done  at  the  TCP/IP 
level  only.  An  authentication  check  is  made  the  first  time  a  client  calls  the  server.  If  the 
client  passes  the  check,  no  authentication  takes  place  during  subsequent  calls  to  the 
server.  In  addition,  an  application  may  completely  disable  Windows  CE  authentication  to 


a  server. 
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Normally,  a  Windows  NT  domain  controller  manages  the  security  credentials  of 
subjects  logging  on  and  authenticates  a  Windows  CE  client  to  a  network.  However,  in 
mobile  situations,  or  when  a  Windows  NT  domain  controller  is  not  available,  a  local 
Windows  CE  database  of  user  names  and  passwords  can  be  created  for  the  Windows  NT 
LAN  Manager  security  package  to  use  for  verifying  credentials.  It  should  be 
remembered  that  Windows  CE  databases  are  unprotected  and  any  Windows  CE 
application  can  access  the  data  contained  in  them.  This  could  possibly  lead  to 
compromise  of  the  Windows  NT  user  names  and  passwords. 

Windows  CE  supports  Secure  Sockets  Layer  (SSL)  versions  2.0  and  3.0  for 
providing  some  measure  of  secure  network  communications.  SSL  is  available  through 
Winlnet  or  directly  from  WinSock.  Applications  can  use  secure  sockets  for  transmitting 
and  receiving  encoded  data.  Windows  CE  maintains  a  database  of  trusted  Certification 
Authorities  independent  of  the  Crypto  API  certificate  store.  Responsibility  for  verifying 
that  a  certificate  is  acceptable  rests  entirely  upon  the  applications. 

The  Crypto  API  provides  services  for  encrypting/decrypting  data,  authentication 
using  digital  certificates,  and  encoding/decoding  of  Abstract  Syntax  Notation  One, 
ASN.l.  ASN.l  is  a  flexible,  abstraction  notation  that  allows  a  variety  of  data  types  to  be 
defined.  Simple  types  such  as  integers  and  bit  strings  can  be  used  to  create  structured 
types  such  as  collections  of  one  or  more  other  types.  Crypto  API  is  compatible  with 
many  CSPs  that  perform  the  actual  cryptographic  functions,  such  as  encryption  and 
decryption,  as  well  as  key  storage  and  key  protection. 

The  Microsoft  cryptographic  system  consists  of  three  elements:  the  operating 
system,  the  applications,  and  CSPs.  Applications  interface  with  the  OS  through  the  CAPI 
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layer,  and  the  OS  communicates  with  the  CSPs  through  the  Cryptographic  Service 
Provider  Interface  (CSPI).  Figure  3.2  from  [ALFOO]  represents  the  relationships  between 
the  three  cryptographic  system  elements. 
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Figure  3.2  Microsoft  Cryptographic  System  Elements  [From:  ALFOO] 

Windows  CE  includes  two  predefined  CSPs.  They  are  the  RSA  Base  Provider, 
which  supports  digital  signatures  and  data  encryption,  and  the  RSA  Enhanced  Provider, 
which  supports  128-bit  key  encryption.  Windows  CE  supports  only  a  subset  of  the 
Crypto  API  2.0  features  present  in  Windows  NT/2000.  The  supported  CAPI  2.0  features 
are  X.509  encoding  and  decoding  of  digital  certificates,  and  certificate  management.  The 
Coredll  module  exports  CAPI  1.0  functions,  and  the  Crypto32  module  exports  CAPI  2.0 
functions.  All  of  the  CAPI  functions  are  defined  in  the  Wincrypt.h  header  file  [ALFOO]. 

If  needed,  designers  can  add  smart  card  functionality  to  their  Windows  CE 
devices  by  supporting  CAPI  through  the  use  of  Smart  Card  Service  Providers  (SCSPs). 
The  Windows  CE  smart  card  subsystem  links  the  smart  card  reader  hardware  and  the 
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applications.  Usually,  the  smart  card  hardware  vendor  provides  the  appropriate  SCSPs. 
Windows  CE  provides  the  subsystem  components  for  the  resource  manager,  resource 
manager  helper  library,  smart  card  reader  helper  library,  and  sample  smart  card  reader 
drivers.  The  smart  card  interfaces  are  exported  by  Windows  CE,  and  it  is  up  to  the 
designer  to  implement  the  system  details  and  interface  with  the  smart  card  reader 
hardware. 

Caution  should  be  taken  when  relying  upon  the  OEM  security  functions,  read¬ 
only  protected  registry  keys,  device  identifiers,  protected  kernel  mode,  application 
security  services,  and  the  dial-up  boot  loader.  These  security  services  can  be  useful,  but 
should  not  be  relied  upon  to  provide  complete  self-protection  of  the  Windows  CE 
operating  system.  Much  of  the  security  is  left  up  to  the  OEMs  to  implement,  if  they  so 
choose,  instead  of  being  enforced  by  the  operating  system  itself. 

For  added  protection,  it  might  be  advantageous  to  place  the  Module  Certify 
functions  in  the  operating  system,  and  ensure  that  those  functions  are  always  used.  The 
trust  level  model  could  be  revised  to  add  more  than  three  levels,  and  to  offer  increased 
granularity.  For  example,  a  trust  level  could  be  defined  that  allows  reputable  sources 
(trusted  code  on  a  Navy  server)  to  update  the  OS  on  a  handheld  device  located  on  a  ship. 
Another  trust  level  could  permit  the  user  of  the  handheld  device  to  update  a  simple 
application,  such  as  a  text  editor,  without  having  the  ability  to  update  the  OS. 

Support  for  the  dial-up  boot  loader  could  be  completely  removed,  if  that  feature 
was  not  required.  The  OS  could  be  built  with  protected  (non-kemel)  mode  only,  to 
provide  more  memory  protection.  By  making  careful  design  choices  at  build  time,  the 
self-protection  of  the  operating  system  configuration  could  be  enhanced. 
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IV.  WINDOWS  CE  PENETRATION  TESTING 


A.  INTRODUCTION 

Penetration  testing  is  a  method  used  to  discover  the  security  strengths  and 
weaknesses  of  an  operating  system.  Typically,  the  method  is  similar  to  the  white-box 
approach  in  software  testing.  In  white-box  testing,  the  system  design  and  implementation 
are  known  and  can  be  examined  to  determine  if  they  meet  the  requirements.  In  the  class 
penetration  testing  exercise  conducted  at  the  Naval  Postgraduate  School,  the  approach 
taken  was  a  mix  of  white  and  black-box  testing,  due  to  the  fact  that  the  Windows  CE  3.0 
source  code  was  not  available.  Black-box  testing  allows  the  software  engineer  to  derive 
sets  of  input  conditions  that  will  fully  exercise  all  of  the  functional  requirements  of  a 
program  [PRE97].  Black-box  testing  is  done  at  the  interface  level,  without  knowing 
exactly  what  is  contained  “in  the  box”.  This  is  similar  to  some  forms  of  penetration 
testing,  in  that  the  exact  implementation  of  the  system  is  not  always  known,  but  only  how 
it  behaves.  Black-box  techniques  are  applied  in  order  to  determine  the  presence  or 
absence  of  classes  of  errors,  so  that  inferences  can  be  made  about  the  errors  in  the  system 
as  a  whole.  Penetration  testing  techniques  allow  the  identification  of  classes  of  system 
security  vulnerabilities.  Once  the  vulnerabilities  are  identified,  steps  can  be  taken  to 
eliminate  them. 

People  of  very  different  backgrounds  break  into  computer  systems  for  a  variety  of 
reasons:  malicious  hackers  testing  their  skills,  disgruntled  employees  seeking  revenge,  or 
those  engaging  in  episodes  of  serious  espionage.  In  each  case,  computer  systems  are 
inviting  targets  for  attack.  Security  testing  attempts  to  verify  that  the  protection 
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mechanisms  built  into  a  system  will,  in  fact,  protect  it  from  obvious  attacks.  In  order  to 
try  out  the  protection  mechanisms  of  Windows  CE,  penetration  testing  was  performed  on 
the  Maxall  configuration  of  Windows  CE  3.0,  installed  on  three  CEPCs  in  a  research  lab 
environment  (see  Appendix  A  for  more  details).  The  testing  was  conducted  during  a 
three  month  time  span  by  students  of  the  Naval  Postgraduate  School  enrolled  in  the 
course  CS  4600,  Secure  Systems,  in  the  Fall  of  2000.  The  course  was  taught  by 
Professor  Cynthia  Irvine. 

Penetration  testing  on  Windows  CE  was  done  to  assess  the  system’s  overall 
vulnerability  to  attack.  Two  major  goals  were  to  test  for  correct  functional  behavior  and 
to  examine  the  penetration  resistance  of  the  system.  The  CE  OS  was  probed  for  any 
obvious  problems,  such  as  design,  implementation,  or  configuration  errors.  During  the 
penetration  testing  exercise,  the  teams  attempted  to  circumvent  the  security  features  of 
the  system,  and  tried  to  exploit  design  weaknesses  as  well  as  undocumented  interfaces. 

B.  THE  FLAW  HYPOTHESIS  METHOD 

Clark  Weissman  originated  the  idea  of  the  Flaw  Hypothesis  Method  (FHM).  FHM  is 
explained  in  the  paper  by  Richard  Linde,  written  when  he  was  employed  by  the  System 
Development  Corporation  [LIN75].  FHM  was  applied  to  several  operating  systems, 
including  Adept  50,  GCOS,  CP67,  VM/370,  KVM/370,  and  MVS.  It  was  incorporated 
into  the  TCSEC  evaluation  process  of  high  assurance  systems  [DOD85].  FHM  provides 
a  systematic  way  to  conduct  system  penetration  testing  and  is  composed  of  six  main 
phases.  The  phases  are  as  follows: 

1.  definition  of  purpose  and  goals 

2.  background  study 

3.  brainstorming  and  flaw  hypothesis  generation 

4.  flaw  hypothesis  verification 
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5.  generalization  of  system  weaknesses 

6.  documentation  of  results 

FHM  is  somewhat  cyclic  in  nature,  because  the  phases  from  background  study  to 
hypothesis  verification  can  be  repeated  as  needed  or  until  time  constraints  are  imposed. 
Results  from  applying  FHM  to  a  system  can  be  used  to  isolate  generic  system  functional 
flaws  which  can  point  to  areas  of  the  OS  design  needing  revision.  The  success  of  FHM 
does  depend  in  part  on  the  experience  of  the  penetration  team  personnel  and  their 
familiarity  with  the  system  being  tested.  However,  even  for  relatively  inexperienced 
teams,  FHM  provides  a  logical  framework  in  which  to  approach  the  penetration  testing 
exercise.  FHM  views  flaws  as  undocumented  capabilities,  and  penetration  is  defined  as 
exploitation  of  those  flaws.  The  FHM  team  attempts  to  systematically  discover  flaws  in 
the  target  system. 

1.  Definition  of  Purpose  and  Goals 

Phase  one  of  FHM  involves  defining  the  purpose  and  testing  goals.  First,  a 
baseline  must  be  established.  The  testers  should  decide  on  the  criteria  for  success,  based 
upon  the  details  of  their  particular  exercise.  The  subject  of  the  analysis  should  be 
determined,  and  the  testers  should  bound  the  environment  and  establish  the  available 
resources.  The  purpose  behind  the  penetration  testing  helps  define  the  entire  testing 
process.  The  testing  can  be  done  for  various  reasons,  such  as  certification  purposes,  as 
part  of  a  risk  assessment,  or  for  research.  In  our  case,  the  course  requirements  set  the 
goals  for  our  penetration  testing.  This  focused  the  analysis  and  defined  specific  criteria 
for  success. 
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2.  Background  Study 

Background  study  is  the  focus  of  phase  two  in  the  penetration  testing 
methodology.  The  optimal  FHM  team  would  already  be  experienced  with  software 
systems,  security  products,  penetration  tools,  penetration  methodologies,  historical 
penetration  information,  and  known  system  vulnerabilities.  However,  a  background 
study  should  be  done  in  order  to  understand  the  target  system  and  its  specific 
configuration.  There  are  many  sources  for  background  study  materials.  System 
documentation,  user  documentation,  configuration  documentation,  and  bug  reports  were 
all  utilized  in  the  background  study  phase.  If  available,  design  documentation,  discussion 
with  the  design  team,  and  implementation  source  code  can  also  be  used  in  the 
background  study  phase  to  determine  what  the  designers  intended  for  the  system. 
During  the  background  study,  potential  weaknesses  can  be  found  by  paying  attention  to 
what  the  designers  recommend  not  to  do.  Operator  commands  and  messages  can 
sometimes  be  exploited.  All  the  implications  of  rarely  used  functions  might  not  have 
been  considered  by  the  designers.  Generic  weaknesses  might  be  identified  by  examining 
known  problems  with  the  system.  Without  performing  the  background  study,  the  next 
phase  of  the  FHM  would  not  be  as  effective. 

3.  Brainstorming  and  Flaw  Hypothesis  Generation 

Phase  three  consists  of  brainstorming  and  flaw  hypothesis  generation.  This  is 

where  all  the  background  study,  team  expertise,  and  system  knowledge  combine  to 

produce  the  best  guesses  for  possible  system  flaws.  Team  members  who  are  area  experts 

can  educate  the  rest  of  the  team  on  an  aspect  of  the  system  and  encourage  group 

discussions.  In  our  penetration  testing  exercise,  team  members  became  familiar  with  one 

of  five  areas  and  shared  their  findings  with  the  team.  The  areas  were  the  Object  Store 
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and  File  System,  Process  and  Thread  Management,  Communication  and  I/O,  Memory 
Management,  and  the  Graphics,  Window,  and  Event  Manager  Subsystem  (GWE).  In  this 
phase,  Flaw  Hypothesis  Sheets  are  generated.  Each  sheet  documents  the  following 
information:  the  flaw  hypothesis,  problem  identification  number,  the  originator  who 
found  the  flaw,  the  investigator,  references,  type  of  vulnerability,  the  date  of 
investigation,  and  the  date  of  flaw  confirmation.  A  Flaw  Hypothesis  Database  is 
constructed  using  the  data  in  the  Flaw  Hypothesis  Sheets.  The  database  is  essential  in 
completing  a  successful  penetration  test.  Without  a  way  to  organize  and  sift  though  the 
data  gathered,  it  is  hard  to  generalize  the  flaws  into  broad,  useful  categories. 

In  order  to  hypothesize  attacks,  the  common  methods  of  system  penetration  were 
considered.  The  teams  examined  how  spoofing,  masquerades,  unauthorized  access, 
covert  processes,  pre-existing  debugging  entry  points,  and  denial  of  service  (DOS) 
through  resource  utilization  would  apply  to  Windows  CE.  The  teams  also  searched  for 
design  errors,  bad  design  assumptions,  and  compromises  that  were  made  to  achieve  better 
performance.  As  Flaw  Hypotheses  were  generated,  each  team  examined  them  and 
discarded  the  ones  that  were  incorrect  or  outside  the  scope  of  the  testing.  The  remaining 
hypotheses  were  prioritized  in  terms  of  ease  of  exploitation,  probability  of  success,  and 
likely  payoff. 

4.  Flaw  Hypothesis  Verification 

The  fourth  FHM  phase  consists  of  the  verification  of  the  Flaw  Hypotheses  that 
were  generated  in  phase  three.  Gedanken,  or  thought  experiments,  were  done  with  the 
information  gathered  in  the  background  study.  Often,  the  validity  of  a  Raw  Hypothesis 
can  be  determined  by  carefully  thinking  through  all  of  the  steps  of  the  penetration 
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experiment.  The  gedanken  experiments  are  the  most  important  phase  of  the  penetration 
study,  due  to  the  fact  that  most  uncovered  flaws  are  found  by  performing  this  type  of 
experimentation  [LEST75].  The  verification  phase  is  often  the  most  difficult  part  of  the 
entire  penetration  exercise,  so  a  time  limit  is  usually  set  for  completion.  Usually  the 
easily  exploitable,  high  payoff  hypotheses  are  considered  first,  and  sometimes  the 
difficult,  low  payoff  hypotheses  are  discarded  in  order  to  avoid  wasting  time  and  effort. 
Public  and  custom  designed  software  tools  can  be  used  to  help  in  the  verification  task. 

5.  Generalization  of  System  Weaknesses 

Phase  five  involves  the  generalization  of  system  weaknesses.  In  order  to  discover 
hidden  trends  of  system  deficiencies,  flaws  should  be  generalized  so  that  they  fit  into 
broad  classes.  Problems  in  one  area  could  possibly  be  mirrored  in  another  area,  so  the 
testers  should  be  aware  of  this  principle  and  exploit  it.  Generalization  of  flaws  is  a  team 
activity,  where  an  inductive  process  may  be  used  to  generate  classes  of  flaws. 

I/O  control  is  often  one  class  of  errors.  Programs  could  have  unrestricted  access 
to  the  system  through  device  drivers.  In  this  area,  there  are  often  semi-privileged 
instructions  and  poorly  designed  protection  mechanisms.  Sometimes  there  are  no 
protection  mechanisms  at  all.  Access  control  is  another  class  of  errors.  There  are  often 
problems  with  configuration,  and  compromises  between  modem  and  legacy  features. 
Some  errors  belong  in  the  class  of  algorithmic  flaws,  such  as  badly  generated  random 
numbers.  Timing  errors  happen  with  unsynchronized  processes,  when  temporary  objects 
are  unexpectedly  modified,  and  when  threads  interact  in  strange  ways.  Data  and  resource 
sharing  allow  for  flaws,  because  shared  memory  can  allow  the  bypass  of  security 
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mechanisms.  Undocumented  functionality  is  another  class  of  flaws,  because  little  known 
hardware  or  interface  features  can  be  exploited  in  unexpected  ways. 

6.  Documentation  of  Results 

Phase  six  of  the  FHM,  the  final  phase,  is  the  documentation  of  results.  In  any 
scientific  testing,  documentation  is  essential  for  establishing  a  permanent  record  of  what 
was  done,  what  was  discovered,  and  what  conclusions  were  drawn  from  the  process.  The 
penetration  testing  experiment  should  be  repeatable,  and  the  documentation  assists  in  the 
effort  to  duplicate  confirmed  attacks.  The  documentation  can  be  used  as  a  starting  point 
for  other  tests,  provides  justification  for  incomplete  testing,  and  may  be  helpful  in 
counteracting  the  weaknesses  found.  However,  open  publication  of  the  findings  might  be 
damaging  to  whoever  owns  the  system,  so  care  should  be  taken  when  releasing 
documentation.  There  is  some  unresolved  debate  as  to  the  best  way  to  deal  with  known 
system  flaws,  with  arguments  both  for  and  against  immediate  public  awareness. 
Basically,  the  release  of  documentation  depends  specifically  upon  the  conditions  in  which 
the  penetration  study  was  done.  Some  circumstances  may  require  that  the  documentation 
becomes  proprietary  information.  In  our  case,  the  study  was  an  academic  exercise 
without  access  to  system  source  code  or  internal  design  documentation.  Therefore,  our 
penetration  study  documentation  was  for  the  benefit  of  the  students  involved. 

C.  LAB  AND  TEST  CONFIGURATION 

For  the  CS  4600  penetration  testing  exercise,  the  class  was  divided  into  three 

teams  of  four  to  five  students.  Each  team,  working  independently,  used  FHM  for 

conducting  penetration  tests  on  the  Windows  CE  3.0  operating  system.  Each  of  the 

members  of  a  team  were  assigned  one  of  the  following  roles:  Lab  Administrator,  Web 

Searcher,  Tools  Manager,  Database  Manager,  and  Report  Editor.  In  addition  to  their  role 
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duties,  each  team  member  investigated  a  Windows  CE  area,  such  as  Memory 
Management,  in  great  detail. 

1.  Penetration  Team  Roles 

The  lab  administrator  was  responsible  for  the  test  hardware  and  software 
installation,  configuration,  and  backups.  The  administrator  also  handled  general  team 
management.  The  web  searcher  scoured  the  Internet  for  any  known  Windows  CE 
penetration  flaws,  and  any  related  flaws  that  might  be  extended  to  apply  to  the  test 
system.  The  searcher  also  looked  for  useful  tools  to  pass  on  to  the  tools  manager,  and  for 
relevant  system  background  information.  The  tools  manager  discovered,  evaluated,  and 
in  some  cases,  created  tools  that  could  be  used  in  the  system  penetration  effort.  The 
database  manager  was  responsible  for  designing,  implementing,  and  managing  a  database 
to  store  all  of  the  generated  flaw  hypothesis  information.  The  report  editor  was  tasked 
with  organizing  and  editing  the  final  written  report  at  the  conclusion  of  the  penetration 
exercise. 

2.  Lab  Setup 

hi  order  to  have  a  baseline  test  environment  for  all  teams,  some  preliminary  lab 

setup  work  was  required.  First,  the  teams  needed  some  Windows  CE  systems  to  attack. 

Since  this  was  a  penetration  testing  exercise,  and  a  goal  was  to  gain  a  deeper 

understanding  of  the  system  operation,  the  flexible  CEPCs  were  used  rather  than  the 

consumer-oriented  handheld  devices.  A  CEPC  is  a  typical  desktop  computer,  with 

specific  hardware,  running  Windows  CE  as  its  operating  system.  In  most  respects,  the 

CEPC  behaves  just  like  its  smaller  cousins.  However,  using  the  Microsoft  Platform 

Builder  tool,  it  is  possible  to  build  a  customized  version  of  CE  by  choosing  components 

and  even  adding  custom  built  ones.  It  is  much  easier  to  download  new  versions  of  CE  to 
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the  CEPCs  rather  than  to  the  Read  Only  Memory  (ROM)  chips  on  handheld  devices.  In 
order  to  maximize  the  penetration  efforts,  the  ability  provided  by  the  CEPCs  to  download 
custom  applications  and  build  system  configurations  was  desired. 

In  the  penetration  testing  lab,  three  test  stations  were  configured.  Each  attack 
team  had  their  own  test  station.  A  test  station  consisted  of  a  CEPC,  otherwise  known  as 
the  target,  and  a  development  Windows  2000  desktop  PC.  The  CEPC  and  development 
computer  were  connected  by  a  local  isolated  network,  and  a  serial  debug  connection  on 
COM1.  For  details  about  the  CEPC,  see  Appendix  A. 

The  following  software  was  installed  on  the  development  PCs:  Platform  Builder 
3.0,  eMbedded  Tools  3.0,  the  Handheld  PC  Software  Development  Kit  (SDK),  the 
PocketPC  SDK,  MS  Office,  and  MS  Visual  Studio.  ActiveSync  3.1,  a  Microsoft 
application  for  synchronizing  and  transferring  files  between  a  desktop  PC  and  a  CE 
device,  was  also  installed  on  the  development  PC.  No  security  protections  other  than  the 
defaults  were  applied  to  the  development  PC.  One  administrator  account  was  configured, 
which  the  team  shared.  A  peculiarity  of  the  Platform  Builder  application  was  that  to  use 
it,  a  person  must  be  logged  on  as  an  local  administrator,  preferably  as  the  administrator 
who  installed  the  software.  If  a  non-administrator  account  was  used,  Platform  Builder 
was  inaccessible.  When  a  user  logged  on  to  an  administrator  account  that  differed  from 
the  account  used  for  installation,  Platform  Builder  behaved  erratically.  So,  to  avoid  these 
problems.  Platform  Builder  was  installed  with  the  administrator  account  given  to  each 
team,  and  everyone  was  advised  to  utilize  those  accounts. 

Once  the  CEPCs  and  development  PCs  were  configured,  the  next  big  challenge 

was  to  establish  communications  between  them.  Major  effort  was  expended  to 
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accomplish  two  tasks:  downloading  a  CE  image  from  the  development  PC  to  the  target, 
and  transferring  files  between  the  two  systems  using  ActiveSync  and  repllog  (a  Windows 
CE  remote  networking  service).  Configuring  the  CEPC  device  networking  (used  for 
Pocket  Internet  Explorer,  etc.)  was  quite  difficult,  and  after  some  effort,  was  abandoned. 
Difficulties  were  also  encountered  when  attempting  to  use  the  Platform  Builder  Remote 
Tools,  which  were  supposed  to  allow  examination  of  the  CEPC  heap  and  registry,  among 
other  features. 

Platform  Builder  can  be  used  to  create  a  platform  and  build  an  OS  image,  as 
explained  in  Appendix  A.  The  OS  image  is  transferred  from  the  development  PC  into 
system  memory  on  the  CEPC.  The  CEPC  is  then  booted  using  a  boot  loader  application 
on  a  CEPC  boot  floppy  disk.  Therefore,  a  CEPC  does  not  require  a  hard  drive,  but 
sometimes  one  is  added  for  the  convenience  of  booting  a  standard  CE  image.  In  our 
penetration  testing  lab,  we  had  two  CEPCs  with  hard  drives,  and  one  CEPC  without. 

A  CEPC  can  be  connected  to  a  development  PC  using  an  Ethernet  or  parallel 
connection,  allowing  an  OS  image  to  be  downloaded  to  the  CEPC.  The  two  options  for 
image  download  and  target  debugging  are  Ethernet  or  parallel  port.  In  both  cases,  debug 
status  messages  are  output  from  the  target  via  the  COM1  serial  port  and  can  be  viewed 
with  the  HyperTerminal  application  on  the  development  PC.  These  status  messages  can 

I 

be  useful  when  troubleshooting  the  development  PC  -  target  connection.  For  our  test 
stations,  the  Ethernet  download  and  debug  option  was  chosen  because  it  was  much  faster 
than  using  the  parallel  port. 

Prior  to  establishing  the  development  PC  —  target  connection,  many  sources  were 
consulted.  The  Platform  Builder  online  help,  and  the  “Microsoft  Windows  CE  Platform 
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Builder  3.0  Getting  Started  Guide”  [MICOOb]  were  used  as  references  for  the  entire 
connection  process.  The  CEPC  vendor.  Special  Computing,  also  offered  invaluable 
assistance  in  setting  up  the  connection.  Useful  information  was  also  found  on  the 
Platform  Builder  newsgroups,  which  are  listed  in  the  references  section  of  this  thesis. 
a.  CEPC  Boot  Disk 

The  first  step  in  the  connection  process  was  to  create  a  CEPC  boot  floppy 
disk.  The  following  procedure  is  given  by  the  “Microsoft  Windows  CE  Platform  Builder 
3.0  Getting  Started  Guide”  [MICOOb]. 

1 .  Run  Websetup.exe,  located  in  the  Program  Files  \  Windows  CE  Platform  Builder  \  3 .0 
\  CEPB  \  Utilities  directory.  By  default,  this  application  installs  Webimgnt.exe  in 
C:\Winnt. 

2.  Run  Cepcboot.  144,  a  disk  image  file  that  is  located  in  the  Program  FilesVWindows  CE 
Platform  Builder\3.0\CEPB\Utilities  directory.  The  Web  Image  NT  dialog  box 
appears. 

3.  Insert  a  floppy  disk  into  the  floppy  drive  on  your  development  workstation,  and  then 
choose  either  Disk  A  or  Disk  B  to  specify  the  floppy  disk  drive  used  to  create  the 
book  disk. 

4.  Click  Cancel  after  the  boot  disk  has  been  created. 

5.  Verify  that  the  boot  disk  contains  the  correct  files. 

Table  4.1  lists  the  files  that  should  be  contained  on  the  CEPC  boot  floppy  disk. 


File  Name 

Description 

Eboot.bin 

This  is  a  binary  file  that  is  an  Ethernet  boot 
loader  component 

Loadcepc.exe 

This  is  an  executable  file  that  loads  the 
boot  loader  image  Eboot.bin 

Autoexec.bat 

This  is  a  batch  application  file  that  must  be 
edited  to  match  your  system  configuration. 

Config.sys,  Himem.sys,  Command.com 

These  are  required  MS-DOS  files 

Readme.txt 

This  file  contains  booting  instructions 

Drvspace.bin 

This  file  adjusts  the  settings  in  the 
Drvspace.ini  file  to  mount  a  drive 

Io.sys,  Msdos.sys 

These  are  MS-DOS  system  files 
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Sys.com 

This  file  is  an  MS-DOS  application 

Vesatest.exe 

This  is  a  DOS  executable  file.  It  tests  the 
VGA  BIOS  on  the  video  card  to  ensure  that 
it  is  compatible  with  the  Windows  CE  3.0 
default  display  driver.  The  Readme.txt  file 
included  on  the  boot  floppy  disk  provides 
additional  information  about  this. 

Table  4. 1  Files  on  the  CEPC  Boot  Disk  [From:  MICOOb] 

If  the  CEPCs  were  purchased  from  Special  Computing,  as  in  our  case,  a 
ready-made  CEPC  boot  floppy  disk  was  provided.  In  addition  to  the  files  listed  above,  a 
directory  named  \DRV\RTL8029  exists  on  the  Special  Computing  boot  disk.  A 
configuration  tool  for  the  network  card  (NIC)  is  included  in  that  directory,  as  well  as  a 
program  net.exe,  which  sets  up  a  NetBEUI  connection.  NetBIOS  Extended  User 
Interface  (NetBEUI)  is  suited  for  use  in  small  workgroups  or  Local  Area  Networks 
(LANs).  It  is  possible  to  install  a  NetBIOS  gateway  and  the  NetBEUI  client  protocol  on 
all  remote  access  servers  running  Windows  2000  and  most  Windows  networking  clients. 
NetBEUI  is  not  routable,  and  the  only  configuration  required  for  the  protocol  is  a 
computer  name.  In  our  penetration  testing  lab,  the  NetBEUI  protocols  were  not  utilized. 

After  a  CEPC  boot  disk  was  obtained,  it  was  necessary  to  modify  the 
autoexec.bat  file  on  the  disk  to  reflect  the  test  station  target  configuration  of  NIC  IRQ, 
base  address,  and  static  IP  address  (if  desired).  There  is  supposed  to  be  a  way  to  leave 
the  IP  address  blank  and  use  Dynamic  Host  Configuration  Protocol  (DHCP),  but  that 
option  was  not  implemented  in  our  penetration  testing  lab. 
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Next,  the  CEPC  network  card  settings  were  determined.  The  easiest  way 
to  accomplish  that  was  to  use  the  utilities  provided  on  the  CEPC  boot  disk.  Upon  system 
boot,  a  menu  was  displayed  on  the  target  as  follows  in  Figure  4.1: 


MS-DOS  6.22  STARTUP  MENU 


1.  Boot  CE/PC  (local  nk.bin) 

2.  Boot  CE/PC  (ether  via  eboot.bin  with  /D:2  (640x480x8)) 

3.  Boot  CE/PC  (ether  via  eboot.bin  with  /L: 1024x768x8) 

4.  Boot  CE/PC  (ether  via  eboot.bin  with  /L: 800x600x16) 

5.  Boot  CE/PC  (ether  via  eboot.bin  with  /L: 640x480x24) 

6.  Boot  CE/PC  (parallel  device) 

7 .  Run  VesaTest  program  and  list  valid  display  modes 

8.  Setup  RTL8029  Ethernet  Adapter 

9.  Clean  Boot  (no  commands) 

Figure  4. 1  CEPC  Boot  Menu 


The  menu  item  8  was  chosen,  Setup  RTL8029  Ethernet  Adapter,  which 
initiated  the  NIC  setup  program.  Then  the  network  card  settings  could  be  observed, 
including  the  NIC  IRQ  and  base  address.  For  our  CEPCs,  the  settings  were  IRQ=9, 
base=D800.  Next,  the  CEPC  boot  floppy  was  taken  to  another  computer  (non-CEPC) 
and  the  autoexec.bat  file  was  edited  to  reflect  our  settings.  Any  ASCII  text  editor  is 
suitable  for  this  purpose,  but  Notepad  was  used.  The  IO  base  address  must  be  specified 
in  hexidecimal,  but  the  IRQ  can  be  either  a  decimal  or  a  hexidecimal  value.  After  the 
REM  comment  block,  the  next  three  set  lines  were  changed  as  follows: 


set  NET_IRQ=9 

set  NET_IOBASE=0  (value  of  0  signifies  an  auto  search  for  the  base  address) 

(D800  could  have  been  used  instead  since  it  was  known) 

set  NET_IP= :  10 . 10 . 10 . 25  (the  static  CEPC  IP  address  belongs  here) 

(note:  it  must  be  on  the  same  subnet  as  the 
Win  2000  development  computer) 
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After  editing,  the  file  was  saved  back  to  the  CEPC  boot  floppy  disk  as 
autoexec.bat.  In  editing  the  file,  there  is  a  major  pitfall  lurking  in  the  “set  NET_BP=” 
line.  In  spite  of  being  mentioned  in  the  autoexec.bat  comments,  it  was  very  easy  to  omit 
the  colon  after  the  equal  sign  and  before  the  valid  static  IP  address.  If  the  colon  is 
omitted,  the  CEPC  and  the  development  workstation  can  not  communicate,  no  matter 
how  many  times  it  is  tried.  So,  it  is  very  important  that  the  set  NETJP  line  is  written  in 
the  following  manner  :  “set  NET_IP= : 10 . 10 . 10 . 25 " .  The  quote  characters  are 
not  included  when  typing  the  line. 

The  CEPC  is  not  Plug-and-Play  enabled,  so  special  care  must  be  taken  to 
prevent  device  IRQ  and  IO  base  address  conflicts.  In  the  readme.txt  file  on  the  CEPC 
boot  disk,  the  default  IRQ  and  IO  base  settings  for  all  standard  CE  device  drivers  are 
listed.  This  list  can  be  checked  for  conflicts  with  the  CEPC  network  card  settings. 

b.  Serial  Debug  Connection 

Now  that  a  CEPC  boot  disk  has  been  created  and  edited,  the  next  step  in 
downloading  a  CE  image  is  to  establish  the  serial  debug  connection  between  the  CEPC 
and  the  development  computer.  CEPC  debugging  text  messages  are  output  via  the  serial 
port  COM1,  and  these  can  be  helpful  in  diagnosing  connection  problems. 

One  would  think  that  any  available  null  modem  cable  would  be  adequate 
for  the  connection  between  the  CEPC  COM1  port  and  the  development  computer  COM1 
port.  Sadly,  this  is  not  the  case.  A  standard  for  the  pin  connections  of  null  modem  cables 
does  not  exist.  A  generic  “null  modem”  cable  will  seem  to  work  for  the  debugging 
messages,  but  will  have  problems  later  on  communicating  with  ActiveSync.  Through  a 
long,  tedious  process  of  lab  experimentation.  Platform  Builder  online  newsgroup 
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research,  and  discussions  with  Special  Computing,  the  correct  cable  pin-out  was 
discovered.  Two  9-pin  female  connectors  were  used.  The  proper  cable  pin  connections 
for  CEPC  to  desktop  computer  communication  are  as  follows  in  Table  4.2.  The  pins 
listed  in  the  End  1  column  should  be  connected  to  the  pins  listed  in  the  End  2  column. 


Cable  Connector  Pins  for  End  1 

Cable  Connector  Pins  for  End  2 

1  and  6 

4 

2 

3 

3 

2 

4 

1  and  6 

5 

5 

7 

8 

8 

7 

9  -  No  connection 

9  -  No  connection 

Table  4.2  CEPC  Serial  Cable  Pin  Connections 


Following  the  discovery  of  the  correct  pin-out,  it  was  learned  that  a  null 
modem  cable  matching  that  description  could  be  commercially  purchased.  The  necessary 
cable  is  a  Belkin  F3B207-10,  Pro  Series,  PC  Compatible,  DB9  Female/Female  File 
Transfer  Cable.  Once  the  cable  is  connected  on  COM1,  output  messages  are 
automatically  sent  from  the  CEPC  upon  system  boot.  These  messages  can  be  viewed 
with  the  Windows  HyperTerminal  application. 
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c.  Ethernet  Downloading 

It  is  possible  to  download  a  Windows  CE  OS  image  from  the  development 
PC  to  the  target  via  an  Ethernet  connection.  In  order  to  download  an  image,  three  main 
steps  must  be  performed.  These  steps  are  : 

1.  Set  up  the  hardware  connections.  Ethernet  cables,  hubs,  and  serial  cables  were  used. 

2.  Edit  the  autoexec.bat  file  on  the  CEPC  boot  disk  to  reflect  CEPC  configuration. 

3.  Configure  the  connection  in  Platform  Builder  on  the  development  PC. 

Steps  one  and  two  were  discussed  above.  Step  three,  configuring  Platform 
Builder,  was  accomplished  using  the  menu  options  of  the  Platform  Builder  Integrated 
Desktop  Environment  (IDE).  After  opening  Platform  Builder  and  building  a  platform, 
Target  /  Configure  Remote  Services  can  be  selected  from  the  menu.  Under  the 
Services  tab,  Ethernet  should  be  selected  in  both  the  Download  and  Debugger  drop- 
boxes.  Figure  4.2  contains  a  screenshot  of  the  required  selections. 


Configure  Remote  Services 


Services  j  Ethernet  j  Parallel  ]  Serial  ] 
Select  a  transport  for  each  service: 


ml 


Download  /  Target  Control  (CESH)  /  Target  Messages  (CETerm): 

: ;  mm 

Debugger: 


o 

|  Ethernet  ▼  ! 

v  Data  VisualizatiqnJoois: 


Service  Settings.., 


Apply  . 

Help 

Figure  4.2  The  Configure  Remote  Services  Dialog  Box  [MICOOb] 
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The  Service  Settings  button  allows  the  configuration  of  the  target 
messages,  target  control  service,  and  the  kernel  debugger.  By  default,  target  messages 
and  target  control  are  started  upon  download.  The  kernel  debugger  configuration  only 
matters  when  a  debug  version  of  the  OS  image  has  been  built.  By  default,  kernel 
debugger  services  are  not  started. 

The  purpose  of  the  next  step  was  to  assist  the  Plaform  Builder  software  in 
recognizing  the  CEPC  target  so  that  a  device  number  could  be  automatically  assigned. 
The  Ethernet  tab  should  be  selected,  as  in  Figure  4.3  below. 


Configure  Remote  Services 


2£j 


Services  Ethernet  J  Parallel  |  Serial  ) 

Reset  a  device  connected  to  the  Ethernet  network  to  automatically  add  it  to  the 
New  devices  list  Click  the  Add  Device  button  to  manually  add  it. 

New  Devices:  ‘  Current  Device: 


Add  Device...  J 


MAC  Address:  : 


IP  Address: 


CE  PULS  231 05 


MAC  Address: 
00400571 5A41 

IP  Address: 
172.30.95.41 


OK 


Cancel 


Apply. 


Help 


Figure  4.3  The  Configure  Remote  Services  Dialog  Box,  Ethernet  tab 

[From:  MICOOb] 


After  reaching  this  stage  on  the  development  computer,  the  CEPC  boot 
disk  was  inserted  into  the  CEPC,  and  the  CEPC  was  reset  by  cycling  its  power.  When 
the  boot  menu  was  displayed  on  the  CEPC,  as  in  Figure  4.1,  menu  choice  3,  “Boot 
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CE/PC  (ether  via  eboot.bin  with  /L:  1024x768x8)”,  was  selected.  This  was  equivalent  to 
selecting  menu  choice  9,  “Clean  Boot”,  and  typing  the  command 
loadcepc  /b:38400  /c:l  /e: 1 : 0 : 9 : 10 . 10 . 10 .25  /v  eboot.bin 
at  the  command  prompt.  The  loadcepc  command  is  documented  in  the  Platform 
Builder  online  help,  and  it  allows  the  loading  and  booting  of  an  OS  image  onto  a  CEPC. 
Figure  4.4  explains  some  of  the  common  options  that  may  be  set  with  loadcepc 
command  switches. 

loadcepc  /to: 38400  /c:l  /e:l: 0:9:10. 10.10. 25  /v  eboot.bin 
/to  =  Connection  Baud  Rate 
/c  =  Serial  Communications  Port  Used 
/e  =  NIC  card  type,  10  base,  IRQ,  and  IP  address 
/v  =  Display  Additional  Status  Information 

eboot.bin  =  file  to  download  from  the  development  PC 

Note:  NIC  card  type  may  be  either :  0  for  a  SMC9000  card 

1  for  a  NE2000  card 

Figure  4.4  Loadcepc  Command  Options 

When  using  the  loadcepc  command,  the  valid  baud  rates  are  9600, 
19200,  38400,  57600,  and  1 15200.  The  default  baud  rate  is  19200.  The  communications 
port  may  be  either  1  for  COM1:  or  2  for  COM2:,  with  the  default  value  of  1.  The  NIC 
card  type  must  always  be  set  to  1,  for  a  NE2000  card  because  the  other  option  is  not 
supported  at  this  time.  The  IP  address  is  optional  if  Dynamic  Host  Configuration 
Protocol  (DHCP)  is  used.  There  is  a  /L  switch  for  setting  the  display  characteristics,  but 
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it  was  not  used  directly.  Instead,  the  /L  switch  was  used  only  indirectly  as  a  choice  from 
the  batch  file  menu. 

Following  a  menu  choice  or  typed  command,  the  CEPC  screen  will  either 
clear  or  display  ‘Jumping  to  0x00132B58  '  .  This  behavior  of  the  CEPC  can  be 
ignored  for  now.  On  the  development  computer,  a  device  number  should  be  displayed  in 
the  New  Devices  text  box  of  the  Configure  Remote  Services  Dialog  Box,  with  the 
Ethernet  tab  selected.  In  order  to  add  the  device  as  the  current  device,  the  arrow  button 
must  be  depressed.  Now  the  device  number  should  appear  in  the  Current  Device  drop¬ 
down  box.  Next,  the  OK  button  was  depressed  to  confirm  the  selection  of  the  current 
device. 

After  the  CEPC  has  been  recognized  by  Platform  Builder,  a  Windows  CE 
OS  image  may  be  transferred  from  the  development  PC  to  the  CEPC.  On  the 
development  PC,  this  was  initiated  by  selecting  Target  /  Download  Image  from  the 
Platform  Builder  menu,  with  the  desired  platform  open.  HyperTerminal  was  also  started 
on  the  development  PC  in  order  to  view  the  CEPC  debug  messages.  The  next  step  was  to 
reboot  the  CEPC,  with  the  boot  floppy  disk  in  the  a:  drive.  The  appropriate  choice  was 
made  from  the  boot  menu,  which  was  number  3,  “Boot  CE/PC  (ether  via  eboot.bin  with 
/L:  1024x768x8)”.  Finally,  the  CEPC  and  development  PC  were  communicating,  and  a 
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progress  bar  appeared  in  Platform  Builder  on  the  development  PC.  After  approximately 
ten  seconds,  the  OS  image  had  downloaded  to  the  CEPC,  and  the  CEPC  booted  up.  The 
CEPC  Windows  CE  3.0  startup  screen  displayed,  which  was  a  very  welcome  sight. 


51 


d.  File  Transfer  Using  Active  Sync 

Besides  downloading  an  OS  image,  another  useful  action  is  to  connect  the 
CEPC  to  the  development  computer  via  ActiveSync  and  repllog.  This  allows  for  the 
transfer  of  files  between  the  two  systems.  In  the  penetration  testing  exercise,  this  file 
transfer  ability  was  made  available  to  place  custom  attack  programs  on  the  CEPCs. 
ActiveSync  is  the  desktop  PC  file  synchronization  utility,  and  repllog  is  the  remote 
networking  component  of  Windows  CE. 

First,  a  physical  serial  connection  had  to  be  made  from  the  CEPC  COMl: 
port  to  the  development  computer’s  COMl  port  using  the  Belkin  cable  discussed  above. 
COM  2  ports  would  work  as  well,  although  the  Platform  Builder  debug  messages  are 
only  output  via  COMl.  Next,  the  ActiveSync  3.0  software  was  installed  on  each 
development  PC.  This  software  can  be  downloaded  from  the  Microsoft  web  site,  and  it  is 
also  included  on  Platform  Builder  installation  disk  1 1 . 

ActiveSync  presents  a  wizard-like  interface  upon  its  first  use,  which  does 
not  allow  access  to  the  connection  settings  menu  until  a  mobile  device  is  recognized  as  a 
valid  connection  partner.  But,  the  ActiveSync  application  does  not  recognize  a  CEPC  as 
a  mobile  device.  This  created  a  problem  in  configuring  ActiveSync.  The  problem  was 
circumvented  by  attaching  a  more  conventional  Windows  CE  device,  in  this  case  a 
Symbol  PPT  2700,  to  its  cradle  with  a  serial  connection  to  COM2  on  the  development 
PC.  The  Symbol  was  recognized  by  ActiveSync  as  a  mobile  device,  and  a  partnership 
with  that  device  was  formed.  Next,  Connection  Settings  was  chosen  from  the 
ActiveSync  menu  bar.  This  action  opened  the  Connection  Settings  dialog  box,  and  the 
com  port  setting  was  changed  from  COM2  to  COMl.  Leaving  this  dialog  box  open  on 
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the  development  PC,  it  was  time  to  initiate  r epilog  on  the  CEPC.  Start  Menu,  and 
Run  were  chosen  on  the  CEPC.  Next,  r epilog  was  typed  at  the  CEPC  command 
prompt.  Back  on  the  development  PC,  a  screen  displayed  which  asked  the  user  if  he  or 
she  would  like  to  create  a  partnership.  The  choice  “NO”  was  selected  in  order  to  connect 
the  CEPC  as  a  guest.  Then,  it  .was  possible  to  transfer  files  between  the  development  PC 
and  the  CEPC.  After  the  initial  connection  was  made,  one  could  connect  later  by  simply 
launching  ActiveSync  on  the  development  PC  and  then  typing  rep  1  log  at  the  CEPC 
command  prompt. 

The  partnership  and  file  synchronization  features  were  not  built  into  the 
Platform  Builder  communication  components  for  incorporation  into  CEPC  OS  image 
builds.  This  means  that  the  CEPC  can  only  connect  as  a  guest,  and  the  development  PC 
will  break  the  connection  if  a  partnership  is  attempted.  There  is  a  Microsoft  QFE  (Quick 
Fix  Engineering)  patch  available  for  download  to  fix  that  problem,  but  it  was  not  used  in 
the  penetration  testing  lab. 

To  summarize,  the  lab  setup  consisted  of  configuring  three  CEPCs,  three 
development  PCs,  and  establishing  OS  image  download  and  file  transfer  capabilities  for 
each  test  station.  After  the  initial  test  station  configuration,  the  responsibility  for 
maintaining  and  tweaking  the  setup  shifted  to  the  administrator  of  each  team. 

D.  PROPOSED  FLAW  HYPOTHESES 

After  several  weeks  of  background  study,  the  penetration  testing  teams  proposed 
several  flaw  hypotheses  in  each  of  the  core  Windows  CE  areas.  Effort  was  made  to 
classify  the  flaws  into  general  classes  of  errors,  in  an  attempt  to  discover  trends  in  the 
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system  weaknesses.  A  selection  of  the  flaw  hypotheses  generated  are  discussed  in  the 
following  sections. 

1.  File  System  /  Object  Store 

This  Windows  CE  subsystem  contains  persistent  storage  such  as  the  CE  file 
system,  registry,  and  property  databases. 

a)  Windows  CE  file  shadowing  allows  for  the  creation  of  a  file  in  RAM  that  has  the 
same  name  as  an  existing  system  ROM  file.  For  all  practical  purposes,  the  newly 
created  RAM  file  supercedes  the  existing  ROM  file.  The  user  can  only  see  the 
RAM  file,  and  that  file  is  executed  instead  of  the  ROM  file.  This  feature  was 
provided  for  the  ease  of  upgrading  system  files  and  drivers.  The  hypothesis  was 
that  an  adversary  could  utilize  the  file  shadowing  capability  to  replace  system 
files  with  malicious  applications.  Also,  the  registry,  which  contains  system 
settings,  could  possibly  be  spoofed  in  this  manner.  [AGAOO],  [BRIOO],  [CLEOO] 

b)  The  property  databases  store  application  data,  such  as  names,  addresses,  and 
phone  numbers.  A  hypothesis  was  proposed  that  an  attacker  could  access  or 
modify  a  user’s  personal  information  through  the  property  databases.  The 
property  databases  could  also  be  covertly  copied  over  a  network  during  device 
synchronozation.  Currently,  there  are  no  access  restrictions  on  these  databases. 
[AGAOO] 

c)  It  was  suggested  that  perhaps  a  malicious  user-defined  file  system  could  be 
installed  and  used  to  compromise  the  OS.  Windows  CE  currently  provides 
support  for  installing  additional  file  systems,  but  there  are  no  administrative 
constraints  on  who  is  allowed  to  install  these  file  systems.  This  implies  that 
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anyone  can  install  file  systems  on  a  CE  device,  potentially  gaining  full  access  to 
the  target  system  and  its  data.  [AGAOO] 

2.  Process  and  Thread  Management 

This  subsystem  contains  the  process  and  thread  model,  and  the  round-robin, 
priority-based  scheduler. 

a)  A  hypothesis  was  proposed  that  since  CE  has  a  shared  memory  space  for  all 
processes,  it  is  possible  for  an  application  to  read  the  memory  area  of  another 
process  with  the  call  ReadProcessMemory.  This  penetration  could  potentially 
lead  to  the  modification  or  theft  of  data.  [AGAOO] 

b)  Another  problem  could  happen  if  a  file  handle  reference  is  moved  so  that  it  points 
to  another  memory  location  after  the  file  has  been  opened.  This  could  allow  the 
file  handle  to  point  to  some  malicious  code,  or  cause  a  denial  of  service  if  a 
critical  file  could  not  be  located.  [AGAOO] 

c)  One  hypothesis  is  that  any  process  has  the  ability  to  terminate  any  other  process. 
If  this  is  the  case,  any  user  application  would  be  able  to  terminate  critical  system 
processes.  A  malicious  process  could  also  terminate  an  application  and  start 
another  one  spoofing  the  original.  [AGAOO] 

d)  A  CE  process  is  not  limited  in  the  number  of  threads  it  can  spawn.  Therefore,  a 
hypothesis  was  that  a  process  could  launch  a  very  large  number  of  threads  and  use 
up  all  of  the  system  memory,  causing  a  denial  of  service.  [AGAOO] 
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3. 


Communication  and  I/O 


This  subsystem  contains  the  native  and  stream  drivers,  the  driver  interface  to  the 
kernel,  networking  support,  ActiveSync  support,  infrared  support,  USB  support,  and 
streams  to  files  or  consoles. 

a)  It  might  be  possible  for  an  application  to  call  the  CreateFile  function  with  a  file 
name  that  is  not  null-terminated.  This  flaw  would  fall  in  the  category  of  buffer 
overflows.  If  the  CreateFile  function  limits  the  number  of  characters  that  it 
copies  into  its  memory  space  by  reading  until  it  reaches  the  null-terminator,  it 
could  be  possible  to  insert  malicious  code  into  the  file  name  string  and  cause 
CreateFile  to  overwrite  its  own  return  stack.  [AGAOO] 

b)  If  the  function  wvsprintf  is  called  with  mismatched  arguments,  it  might  be 
possible  to  discover  some  information  in  the  returned  format  specifier  data 
structure.  This  information  could  be  data  that  would  normally  not  be  provided  to 
the  calling  process.  [AGAOO] 

c)  Another  hypothesis  proposed  the  exploitation  of  the  CE  NetBIOS  net  commands, 
which  are  similar  to  the  Windows  95  NetBIOS  commands  and  might  share  their 
vulnerabilities.  [CLEOO] 

d)  A  denial  of  service  attack  might  be  possible  by  overwhelming  the  CE  device  with 
TCP/IP  packets.  A  program  similar  to  “Win  Nuke”  could  be  used.  This  would  be 
especially  devastating  for  wireless  CE  devices.  [CLEOO] 

4.  Memory  Management 

This  subsystem  deals  with  the  allocation  and  freeing  of  memory,  paging, 
maintaining  the  heap,  and  managing  virtual  memory. 
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a)  One  flaw  hypothesis  in  this  area  is  that  the  cache  manager  might  be  overloaded  by 
preemptively  loading  unnecessary  pages  into  memory.  If  successful,  system 
performance  could  be  downgraded,  causing  many  page  faults  and  possibly 
undermining  the  stability  of  the  system.  [AGAOO] 

b)  Another  hypothesis  is  that  the  system  could  be  kept  busy  flushing  the  cache  for 
long  enough  that  the  network  connection  is  lost.  If  malicious  code  causes  the 
cache  to  flush  for  more  than  two  thousand  milliseconds,  the  network  connection 
could  be  broken  because  the  system  is  not  responding.  This  situation  could  allow 
a  spoof  attack,  because  the  system  network  response  could  be  simulated,  when  in 
fact  the  system  was  down.  [AGAOO] 

c)  It  might  be  possible  to  mark  a  file  as  sequential,  allowing  intelligent  read-ahead  to 
bring  in  the  next  192  KB  in  memory.  The  memory  read  immediately  following 
the  file  could  contain  cryptography  secrets  or  other  important  data.  This  captured 
data  could  be  stored  and  later  exported  to  a  desktop  PC  during  ActiveSync  of  the 
CE  device.  [AGAOO] 

d)  By  modifying  the  read  input  buffer  during  a  read  operation,  it  may  be  possible  to 
create  an  unstable  system  state.  The  Windows  CE  Programming  documentation 
advises  against  doing  this,  because  the  result  is  undefined.  This  is  a  timing  attack 
that  would  have  to  be  repeated  five  or  six  times  before  its  effectiveness  could  be 
ascertained.  [AGAOO] 

5.  Graphics,  Window,  and  Event  Manager  Subsystem 

This  subsystem  contains  the  user  input  system,  the  event  manager,  the  window 
manager,  raster  graphics  API,  touch  screen  driver,  and  font  support. 


57 


a)  The  GWE  module  is  responsible  for  managing  the  power-saving  suspend  mode. 
This  could  possibly  be  exploited  to  turn  off  the  power  saver,  thus  running  down 
the  batteries  and  causing  the  loss  of  files  stored  in  RAM  system  memory.  The 
user  might  believe  that  the  CE  device  would  turn  off  normally,  but  because  the 
timeout  interval  had  been  tampered  with,  the  batteries  could  run  out  and  user  data 
would  be  lost.  [CLEOO] 

b)  Another  flaw  hypothesis  exploits  the  fact  that  the  CE  OS  only  supports  an  8-bit 
color  scheme.  Therefore,  a  denial  of  service  attack  would  run  an  application  that 
would  set  the  resolution  higher  than  8-bit,  causing  the  device  display  to  function 
incorrectly.  [CLEOO] 

c)  Windows  CE  only  supports  a  256  color  palette.  The  OS  does  not  include  a  palette 
manager,  and  there  are  no  checks  to  ensure  that  palette  settings  are  valid. 
Malicious  code  could  manipulate  the  palette  to  support  only  one  color.  This 
would  also  cause  the  display  to  be  unreadable.  [CLEOO] 

d)  There  is  a  problem  with  stale  process  handles  in  the  GWE  subsystem.  When 
applications  are  terminated,  the  handles  to  those  processes  remain  active  instead 
of  being  released.  A  2-bit  reuse  count  indicates  how  many  times  a  slot  in  the 
handle  table  has  been  reused.  The  OS  designers  claim  that  the  reuse  scheme 
works  seventy-five  percent  of  the  time.  However,  the  possibility  of  stale  handles 
exists,  and  could  be  exploited  to  gain  improper  access  to  files  or  memory  areas. 
[BRIOO] 
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6.  Miscellaneous  Flaw  Hypotheses 

The  CE  device  password  may  be  easy  to  crack  due  to  the  fact  that  text  input  is 
limited  on  a  CE  device.  Most  users  will  choose  a  short  password  that  is  easy  to  enter 
using  a  stylus,  and  will  not  use  symbols,  such  as  @  or  $,  in  a  password.  These  habits 
might  cause  the  password  to  be  a  weak  entry  point  to  the  system.  [CLEOO],  [BRIOO] 

Many  CE  devices  include  a  built-in  microphone  for  dictation  and  recording  sound 
clips.  This  hardware  could  be  exploited  by  a  malicious  application  to  record  ambient 
sounds  or  private  conversations  while  the  user  was  unaware  of  the  fact.  [BRIOO] 

E.  PENETRATION  TEST  CONCLUSIONS 

After  intensive  study,  the  penetration  test  teams  were  successful  in  identifying 
potential  flaws  and  vulnerabilities  in  the  Windows  CE  operating  system.  Using  the  Flaw 
Hypothesis  Method,  the  teams  identified  the  main  components  of  the  operating  system, 
discovered  potential  weaknesses  in  those  components,  and  tested  the  weaknesses  through 
gedanken  experiments.  Finally,  the  team  findings  were  documented  to  preserve  the 
system  knowledge  gained. 

Caution  is  recommended  when  using  Windows  CE  due  to  the  lack  of  basic 
security  features,  such  as  authentication  or  a  trusted  path.  Numerous  flaws  were  found 
that  could  be  exploited  to  compromise  system  security.  Also,  by  adding  a  mobile  CE 
device  to  an  existing  computer  network,  a  weakest  link  might  be  introduced  to  the  system 
as  a  whole. 

Windows  CE  does  offer  some  process  separation  features,  and  allows  the  use 
of  certificates  to  install  trusted  modules  at  build  time.  However,  these  features  are 
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inadequate  by  themselves  and  should  be  incorporated  into  a  coherent  security 
architecture. 
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V.  REDESIGN  FOR  SECURITY 


A.  EXISTING  DESIGN 

Because  the  Windows  CE  devices  are  so  versatile  and  mobile,  many 
governmental  uses  for  these  devices  can  be  envisioned.  In  the  rush  to  incorporate  new 
technology,  we  should  keep  in  mind  how  it  will  affect  existing  computer  systems  and 
networks.  Especially,  the  security  impact  of  the  new  technology  should  be  examined. 
Using  wireless  PDAs  may  be  convenient  and  time-saving,  but  the  devices  could 
introduce  a  weakest  link  in  the  overall  systems  security  because  of  the  current  design  of 
the  operating  system.  By  taking  a  closer  look  at  the  components  and  design  of  Windows 
CE,  we  can  make  suggestions  on  how  to  improve  its  self-protection. 

1.  Windows  CE  Design  Goals 

The  Windows  CE  operating  system  was  first  introduced  in  1996.  It  was 
specifically  designed  for  supporting  embedded  applications,  which  are  typically  limited 
in  resources.  There  are  many  applications  for  devices  based  upon  the  Windows  CE  OS. 
A  few  examples  are  commercial  building  automation  systems,  handheld  communications 
devices,  manufacturing  process  controllers,  and  medical  data  acquisition  devices. 

A  major  design  goal  of  Windows  CE  was  to  support  the  requirement  of  minimal 
memory  usage.  The  size,  or  footprint,  of  the  operating  system  itself  can  be  controlled  by 
adding  or  removing  modules  to  obtain  the  specific  desired  configuration.  Several  of  the 
modules  can  be  further  divided  into  components,  for  increased  flexibility.  Hardware 
resources  such  as  ROM  and  RAM  can  be  minimized  for  a  particular  system  design  by 
selecting  a  minimum  set  of  modules  and  components.  Component  modules  are  defined 
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by  Microsoft  as  Windows  CE  modules  that  include  one  or  more  optional  components. 
Examples  of  component  modules  include  Coredll,  Gwes,  Filesys,  and  01e32.  These 
component  modules  can  be  customized  to  meet  the  needs  of  the  embedded  application 
designer. 

Three  key  design  decisions  were  made  in  Windows  CE.  The  first  decision  was  to 
partition  the  operating  system  design  into  modules,  in  order  to  support  hardware  upgrades 
and  enhance  system  flexibility.  Second,  Microsoft  decided  to  build  a  portable  OS  that 
would  not  depend  on  just  one  OEM  for  the  device  platform.  This  allows  OEMs  the 
choice  of  several  processors  to  choose  from  to  fit  their  project  needs.  Third,  they 
considered  what  the  system  would  be  used  for,  and  what  capabilities  might  be  desired. 
For  example,  since  it  was  determined  that  only  a  limited  number  of  applications  would 
be  running  at  any  given  time,  the  OS  was  limited  to  supporting  thirty-two  processes. 
Also,  in  order  to  relax  the  level  of  code  redundancy,  the  OS  kernel  was  allowed  the 
ability  to  possibly  corrupt  applications.  The  designers  knew  the  kernel  would  not  be  very 
secure,  but  it  was  viewed  as  a  reasonable  compromise.  However,  some  protections  were 
built  in  so  that  the  applications  would  have  a  harder  time  inadvertently  crashing  the 
kernel.  For  compatibility,  the  designers  decided  to  support  a  subset  of  the  Win32  API. 
This  provided  Win32  applications  programmers  a  jump  start  to  writing  Windows  CE 
applications. 

2.  Building  Windows  CE 

A  Windows  CE  system  can  be  built  using  Microsoft  Platform  Builder  (PB). 
Version  3.0  is  the  current  release  at  the  time  of  this  writing,  and  it  supports  the  data 
visualization  tool  as  well  as  kernel  debugging  and  profiling.  Data  visualization  allows 
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the  developer  to  visually  monitor  and  track  the  state  of  system  data  while  a  platform 
operating  system  executes.  Since  Windows  CE  can  be  customized  to  support  a  small 
footprint  with  a  subset  of  desired  features  built  in,  the  general  approach  is  a  modular  one. 
A  system  is  built  using  a  platform,  a  project,  and  various  modules,  which  are  composed 
of  components.  Microsoft  defines  a  module  as  an  executable  or  dynamic-link  library  that 
usually  implements  self-contained  functionality.  A  module  contains  components  that 
can  be  replaced  or  removed  as  needed.  In  order  to  meet  the  constraints  set  for  a  system’s 
memory  requirements,  careful  thought  should  be  given  as  to  which  modules  and 
components  to  include.  PB  provides  seven  sample  project  configurations  that  have  been 
tested  and  are  guaranteed  to  work.  These  configurations  range  from  Minkem,  with  a 
minimal  kernel  and  a  very  simple  application,  to  Maxall,  which  is  the  complete  version  of 
CE,  including  a  soft  input  panel,  handwriting  recognition,  WinNET  FTP  and 
communication  applications.  It  is  strongly  recommended  that  new  systems  be  based 
upon  one  of  the  provided  configurations.  There  are  several  environment  variables  that 
can  be  set  to  modify  the  pre-tested  configurations.  The  environment  variables  are 
contained  in  the  file  Cesysgen.bat.  It  is  interesting  to  note  that  the  password  component 
can  be  removed  from  the  Minkem  configuration,  and  the  security  component  can  be 
removed  from  the  Mincomm  configuration.  However,  for  a  dedicated  embedded  device, 
the  password  or  security  components  might  not  be  required 

A  system  generation  phase  (Sysgen)  was  added  to  support  componentization. 
Sysgen  integrates  a  built  version  of  the  OS,  installed  with  Platform  Builder,  that  has  all 
the  libraries  for  all  the  components,  the  master  header  files,  the  module  definition  files, 
and  a  configuration  file  that  specifies  the  desired  components.  Three  tasks  are  performed 
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during  the  Sysgen  phase.  The  selected  and  necessary  parts  of  the  OS  are  linked  together, 
the  master  header  files  are  filtered  to  take  out  the  parts  that  aren’t  exposed  by  the  selected 
components,  and  the  module  definition  files  (.DEF)  are  filtered  so  that  only  the  desired 
functions  are  exported. 

Componentization  was  good  in  that  it  allowed  four  major  benefits.  They  are: 
scalability,  the  ability  for  OEMs  to  make  system  design  tradeoffs,  the  ability  for  OEMs  to 
replace  code  with  their  own  customized  version,  and  minimizing  the  overhead  as  new 
features  are  added  to  the  system. 

Two  of  the  big  problems  encountered  in  componentization  were  dependencies  and 
configuration  testing.  All  of  the  logical  units  that  already  had  interfaces  were  made  into 
separate  components,  such  as  the  Graphics,  Window  and  Event  Manager  (GWE)  module. 
Unfortunately,  approximately  ten  percent  of  the  system  was  not  very  modular  at  first  and 
so  it  was  hard  to  break  it  into  components.  For  example,  someone  might  want  to  build  a 
system  that  had  communications  without  a  window  manager,  but  because  the  system 
used  the  PostMessage  function  and  PostMessage  used  something  else  in  the  window 
manager,  the  window  manager  would  have  to  be  included  anyway.  The  modules  were 
rewritten  for  Windows  CE  2.0  with  the  goal  of  isolating  dependencies  across  the 
modules. 

Componentization  also  resulted  in  difficulties  in  testing  all  of  the  possible 
configurations.  For  just  ten  components  that  could  be  either  included  or  excluded,  the 
Quality  Assurance  department  would  have  to  test  a  great  number  of  possible 
configurations.  As  the  number  of  components  increases,  the  amount  of  testing  quickly 
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becomes  unmanageable.  The  Microsoft  designers  decided  to  compromise  and  allow  a 
limited  set  of  component  configurations  to  be  chosen. 

B.  WINDOWS  CE  KERNEL  MODULES 

The  Windows  CE  kernel  consists  of  modules  and  components,  which  are  listed  in 

Table  5.1. 


1.  Module  Listing 


Module 

Description 

Components 

Coredll 

Operating  core 
dynamic  link  library 

accel_c,  coreimm, 
coreloc,  coremain, 
coresioa,  coresiow, 
coresip,  corestra, 
corestrw,  cryptapi, 
fileinfo,  fileopen, 
fmtmsg,  fmtres, 
lmem,  mgdi_c, 
rectapi,  rsa32,  serdev, 
shcore,  shexec, 
shmisc,  shortcut, 
tapilib,  thunks, 
wavelib,  wmgr_c 

Nk 

Windows  CE  kernel 

Table  5.1  Kernel  Modules  Table  [From:  GAR99] 

In  Coredll,  the  only  required  components  are  coremain,  lmem,  and  thunks. 
Coremain  contains  the  Windows  CE  base  functionality.  Lmem  is  the  local  heap.  Thunks 
is  the  name  of  the  component  that  handles  the  older  16-bit  code,  making  the  OS 
backwards  compatible.  The  thunks  component  takes  care  of  the  kernel  to  Win32 
thunking  mechanism.  The  generic  thunking  mechanism  provides  functions  that  allow  a 
16-bit  application  to  load  a  Win32-based  DLL,  get  the  addresses  of  its  exported 
functions,  call  the  functions,  convert  addresses,  and  free  the  Win32-based  DLL. 
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C.  WINDOWS  CE  OBJECT  STORE  MODULES 

1.  Design  Background 

The  CE  object  store  and  file  system  are  quite  different  from  the  Windows  NT  file 
system.  An  obvious  difference  in  CE  is  the  lack  of  any  of  the  types  of  security  protection 
offered  by  the  NT  model. 

The  CE  object  store  provides  persistent  storage  that  is  available  for  use  by 
applications.  It  is  the  part  of  memory  not  in  use  by  the  operating  system,  and  is  built  on 
the  internal  heap  using  the  system  RAM,  ROM,  and  optionally  mounted  PC  cards.  The 
maximum  size  of  the  object  store  is  256  MB  for  CE  version  3.0,  and  16  MB  for  previous 
versions.  The  object  store  has  three  main  components:  the  file  system,  the  registry,  and 
property  databases. 

There  were  four  major  design  goals  for  the  heap.  The  Microsoft  designers  wanted 
it  to  be  small  to  conserve  memory.  They  also  wanted  the  heap  to  be  robust  against  power 
loss  and  crashing.  They  needed  it  to  be  fast,  and  have  a  small  working  set. 

A  new  proprietary  file  system  was  implemented  in  order  to  minimize  overhead 
and  get  the  most  out  of  the  available  storage  memory.  The  file  system  is  a  lightweight 
layer  on  top  of  the  heap  that  supports  files  stored  in  ROM  as  well  as  files  stored  in  RAM. 

One  interesting  thing  about  the  file  system  is  that  it  allows  file  shadowing.  If  a 
file  is  created  in  RAM  that  has  the  same  name  as  an  existing  ROM  file,  the  RAM  version 
shadows  the  ROM  file.  This  means  that  only  the  RAM  file  attributes  are  seen,  and  the 
RAM  file  is  executed  instead  of  the  ROM  file  of  the  same  name.  The  ROM  file  is  still 
there,  but  you  can’t  access  it.  If  the  RAM  file  is  deleted,  the  ROM  file  attributes  will  be 
seen  again.  Shadowing  means  that  you  can  hide  the  ROM  file  size,  but  not  its  name. 
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The  CE  registry  is  similar  to  the  one  found  in  Windows  NT,  but  it  is  a  limited 
subset.  However,  it  is  Win32  compatible.  The  registry  stores  data  about  applications, 
drivers,  user  preferences,  and  other  configuration  settings.  The  data  stored  in  the  registry 
is  persistent  and  shared  among  all  applications.  In  the  Windows  CE  registry,  there  is  no 
way  to  deny  read  access  to  applications.  Therefore,  care  should  be  taken  when  storing 
data  in  the  registry  because  there  is  no  real  way  to  protect  the  data.  The  registry  uses  the 
native  logging  and  transactioning  of  the  heap.  Since  CE  does  not  support  the  registry 
security  features,  a  default  security  descriptor  is  assigned  to  the  CE  registry  keys. 

It  is  very  likely  that  the  CE  registry  is  vulnerable  to  the  same  types  of  attacks  used 

♦ 

on  the  NT  registry.  The  CE  registry  shares  common  functionality  with  the  NT  registry, 
but  has  none  of  the  NT  registry  security  features,  so  that  will  offer  possibilities  for 
exploits.  The  CE  registry  may  be  stored  on  a  PC  card  and  copied  into  a  device’s  system 
RAM  at  boot-up.  This  could  offer  a  possible  way  to  overwrite  the  valid  registry  with 
whatever  keys  are  desired. 

The  final  component  of  the  object  store  is  the  property  database.  Property 
databases  store  application  specific  data,  and  can  be  built  on  the  internal  heap  or  on 
mounted  volumes.  The  property  databases  are  loosely  based  on  the  Microsoft  Messaging 
API  (MAPI).  Examples  of  applications  that  use  the  property  databases  are:  Inbox, 
Calendar,  and  Tasks. 

In  a  CE  property  database,  only  one  level  of  hierarchy  is  allowed.  This  means 
that  a  record  cannot  contain  another  record.  A  single  record  cannot  be  shared  among 
databases,  and  it  is  not  possible  to  lock  a  database  to  restrict  access.  Transactioning 
occurs  after  each  individual  database  call. 
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There  are  at  least  three  ways  to  access  a  property  database.  The  Pocket  Access 
application,  CE  API  functions,  and  Microsoft  Foundation  Classes  (MFC)  can  all  be  used. 
Active  Data  Objects  (ADO),  which  are  used  to  access  relational  databases,  may  also  be 
used. 

D.  WINDOWS  CE  I/O  AND  COMMUNICATIONS  MODULES 

Windows  CE  provides  many  options  for  communication  with  the  desktop,  the 
Internet,  and  other  Windows  CE  devices.  The  OS  supports  a  variety  of  Win32 
communication  APIs  for  modems,  networks,  and  serial  and  infrared  communications. 
Smartcards,  external  file  systems,  and  flash  memory  can  also  be  incorporated.  Native 
drivers  provide  support  for  graphics,  the  touch  screen,  and  audio,  among  other  things. 
Stream  drivers  exist  for  serial  communications.  Network  and  Universal  Serial  Bus 
(USB)  drivers  are  also  supported. 

1.  Windows  CE  Driver  Model 

The  OEM  Adaptation  Layer  (OAL)  is  the  layer  between  the  device  hardware  and 
the  Windows  CE  kernel.  It  is  comparable  to  the  Hardware  Abstraction  Layer  (HAL)  in 
Windows  NT.  When  considering  the  CE  driver  model,  it  is  somewhat  instructive  to  think 
of  the  components  being  arranged  in  layers,  with  hardware  at  the  bottom.  Next  comes 
the  OAL,  and  various  drivers  that  interface  directly  with  the  hardware.  Above  the  OAL 
are  the  CE  kernel,  the  window  manager  and  user  subsystem  GWE,  and  the  device 
module.  However,  the  model  is  not  composed  of  true  layers,  because  the  drivers  can 
communicate  directly  with  the  hardware,  bypassing  the  OAL,  and  can  also  communicate 
with  the  kernel  and  the  GWE  module.  In  fact,  the  native  drivers,  which  include  display, 
battery,  keyboard,  audio,  and  touch  screen,  are  a  part  of  GWE.  Some  driver  services  are 
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exported  in  the  Device  module  to  make  writing  drivers  for  serial  and  PC  card  devices 
easier. 

There  are  four  main  categories  of  Windows  CE  device  drivers:  native  drivers, 
stream  interface  drivers,  NDIS  network  drivers,  and  USB  drivers.  The  native  device 
drivers  are  linked  with  the  OS.  The  stream  drivers  can  be  installed  at  any  time.  Because 
exploring  all  of  the  drivers  in  detail  is  beyond  the  scope  of  this  thesis,  the  concentration 
will  be  placed  on  the  stream  drivers.  A  summary  will  be  given  for  the  other  driver  types. 
Sample  drivers  of  all  types  are  provided  in  the  Windows  CE  Device  Driver  Kit. 

To  understand  where  the  drivers  fit  into  the  big  picture,  it  helps  to  take  a  look  at 
the  system  startup  sequence.  When  a  Windows  CE  device  is  turned  on,  the  hardware  is 
first  initialized.  Next,  the  OEM  startup  code  runs.  After  that,  the  kernel  is  initialized, 
then  the  OEM  init  function  runs,  which  is  one  of  the  OAL  functions  inside  of  the  Nk 
module  in  Nk.exe.  The  kernel  start  up,  then  the  Filesys,  GWE,  Device,  and  other 
modules  are  loaded.  Finally,  GWE  loads  up  the  native  drivers  and  Device  loads  the  other 
drivers.  User  level  stream  drivers  can  also  be  loaded  at  any  time  thereafter. 

2.  Native  Drivers 

The  native  device  drivers  are  split  into  two  parts:  the  module  device  driver 
(MDD)  and  the  platform  device  driver  (PDD).  These  driver  models  are  unique  to 
Windows  CE,  and  are  provided  for  convenience.  Usage  of  these  models  is  not  required, 
but  is  highly  encouraged.  The  MDD  provides  the  interface  to  Win32,  which  allows  the 
OEM  to  make  changes  only  to  the  PDD.  Through  the  PDD,  the  OEM  can  control  the 
hardware,  without  having  to  worry  about  the  software  interface  from  the  driver  to  Win32. 
So,  the  OEM  has  the  choice  of  writing  a  monolithic  driver,  or  just  implementing  a 
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smaller  piece  that  interacts  with  the  MDD.  The  print  and  display  drivers  are  monolithic. 
Each  monolithic  native  driver  must  export  a  specific  set  of  functions,  called  the  Device 
Driver  Interface  (DDI).  The  DDI  is  called  by  the  GWE  module  at  run-time.  The  layered 
drivers  use  another  interface  called  the  Device  Driver  Service-provider  Interface  (DDSI). 
That  interface  consists  of  the  PDD  functions  that  are  called  by  the  MDD.  The  touch 
panel,  keyboard,  PC  card  socket,  and  USB  drivers  are  layered  drivers. 

3.  Stream  Drivers 

Stream  drivers  are  a  generic  type  of  driver,  because  they  always  expose  the  same 
functions.  This  is  in  contrast  to  native  device  drivers,  which  have  a  unique  interface. 
Stream  drivers  are  typically  used  for  third-party  devices  such  as  bar-code  scanners,  GPS 
receivers,  and  IR  receivers.  Using  the  stream  driver  interface,  devices  are  presented  as  a 
type  of  special  file,  and  use  the  file  system  API  to  interact  with  applications.  For 
example,  the  CreateFile  function  would  open  a  device.  Stream  drivers  are  loaded  by 
either  the  Device  module  or  by  specific  applications,  instead  of  by  the  GWE  module  like 
native  drivers.  They  are  usually  implemented  as  Dynamic-Link  Libraries  (DLLs)  and  are 
located  in  the  Windows  directory. 

There  is  a  strict  naming  convention  for  stream  drivers.  The  format  is  three  upper¬ 
case  letters,  followed  by  a  single-digit  index  (1-9,  and  0  used  for  10),  with  a  colon  at  the 
end.  For  example,  “COM1:”  is  a  valid  name  for  the  first  serial  port.  The  three  letters  act 
as  a  key  to  access  the  driver  functions,  and  the  digits  identify  a  specific  drivers. 

There  is  a  user-level  process  called  the  Device  Manager  Module  that  acts  as  an 
interface  between  the  kernel,  registry,  and  stream  interface  drivers.  Its  main  purpose  is  to 
load  and  unload  stream  devices  as  needed.  There  are  three  ways  that  stream  drivers  can 
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be  loaded.  One  way  is  at  boot  time.  Upon  boot,  Device  Manager  loads  all  the  drivers 
listed  under  the  HKEY_LOCAL_MACHINE\Drivers\Builtin  registry  key.  Another  way 
of  loading  is  when  a  device  is  connected.  For  example,  when  a  PC  card  is  connected,  the 
Device  Manager  calls  the  native  socket  driver  to  get  a  Plug  and  Play  identifier.  That  id 
is  then  checked  against  the  registry  values  in  the  key 
HKEY_LOCAL_MACHINE\Drivers\PCMClA.  If  found,  the  driver  is  loaded.  If  not 
found,  the  Device  Manager  calls  the  detection  functions  listed  in 
HKEY_LOCAL_MACHINE\Drivers\PCMCIA\Detect.  If  one  of  the  functions  can 
handle  the  device,  the  Device  Manager  registers  that  driver  for  the  device.  The  last  way 
to  load  a  stream  driver  is  used  when  an  application  tries  to  open  an  unloaded  driver.  The 
application  can  load  the  device  itself  and  then  open  and  access  it.  This  last  scenario 
typically  happens  with  devices  like  digital  cameras. 

There  are  two  ways  to  unload  stream  drivers.  If  the  Device  Manager  is  notified  of 
the  disconnection,  the  corresponding  entry  is  removed  from 
HKEY_LOCAL_MACHINE\Drivers\Active.  The  Device  Manager  also  calls  the 
DeregisterDevice  function  to  remove  the  device  name  from  the  file  system  and 
FreeLibrary  to  unload  the  DLL  from  memory.  Alternatively,  if  an  application  loaded 
the  stream  device,  then  the  application  has  to  unload  the  DLL  from  memory  on  its  own. 
If  it  fails  to  do  this,  some  of  the  valuable  memory  storage  space  will  be  wasted  holding  a 
DLL  that  is  not  being  used. 

All  stream  interface  drivers  should  implement  some  standard  functions.  The 
functions  and  their  descriptions  are  listed  in  Table  5.2. 
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Driver  Function 

Description 

???_Close  ( ) 

Closes  the  device  associated  with  a  handle 

???_Deinit  ( ) 

Device  Manager  calls  this  to  de-initialize  the  driver 

???_Init  ( ) 

Device  Manager  calls  this  to  initialize  the  driver 

???_IoControl  ( ) 

Sends  a  device-defined  command  to  the  driver 

???_Open  ( ) 

Opens  a  device  for  reading  or  writing 

???_PowerDown  ( ) 

Powers  down  the  device,  if  capable 

???_PowerUp  ( ) 

Powers  up  the  device 

???_Read  ( ) 

Reads  data  from  the  device 

???_Seek  ( ) 

Moves  the  data  pointer  within  the  device 

???_Write  ( ) 

Writes  data  to  the  device 

Table  5.2  Stream  Driver  Functions  [From:  GAR99] 


Stream  drivers  can  be  used  either  by  a  single  application  at  a  time,  or  by  multiple 
applications,  depending  on  whether  a  handle  to  the  device  or  NULL  is  returned  by  the 
???_Open  function.  This  allows  the  designer  to  decide  which  policy  best  fits  the 
anticipated  device  usage. 

4.  NDIS  Network  Drivers 

The  Network  Driver  Interface  Specifications  (NDIS)  drivers  used  in  Windows  CE 
are  derived  from  Windows  NT.  They  allow  networking  protocols  like  TCP/IP  and  IrDA 
to  be  independent  from  a  network  interface  card  (NIC).  Windows  CE  supports  Ethernet 
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and  IrDA  miniport  drivers  that  conform  to  the  NDIS  4.0  implemented  in  Windows  NT. 
NDIS  provides  the  glue  between  the  network  interface  cards,  the  network  drivers,  and  the 
network  protocol  stacks.  However,  monolithic  network  drivers  and  full  NIC  drivers  are 
not  supported  under  Windows  CE  NDIS.  Some  other  features  that  are  not  supported  are: 
general  direct  memory  access,  contiguous  physical  memory  allocations,  and  wide  area 
networking  through  NDIS.  For  miniport  drivers,  Windows  CE  is  mostly  source-code 
compatible  with  Window  NT,  so  they  share  almost  identical  NDIS  APIs.  This  fact 
speeds  up  Windows  CE  driver  development  time  for  people  who  are  already  familiar 
with  Windows  NT  miniport  drivers. 

5.  USB  Drivers 

Universal  Serial  Bus  (USB)  is  an  external  bus  architecture  for  connecting  USB- 
compatible  peripheral  devices,  like  a  mouse  or  keyboard,  to  a  host  computer.  USB  was 
not  designed  for  use  as  an  internal  bus,  but  rather  as  a  communication  protocol  that 
supports  serial  data  transfers  between  a  host  system  and  its  USB-compatible  peripherals. 
Today,  you  can  find  USB  connectors  on  common  items  like  joysticks,  digital  cameras, 
MP3  players,  and  PDAs.  USB  provides  a  single,  well-defined  connector  type,  supports 
hot  plugging  and  Plug  and  Play,  and  provides  power-saving  and  suspend  modes.  There  is 
currently  no  support  for  connecting  a  Windows  CE  device  as  a  USB  peripheral  to  a  host 
computer. 

6.  Module  Listing 

Table  5.3  describes  the  modules  that  are  related  to  common  native  and  stream  I/O 

drivers. 
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Module 


Device 


Elnk3 


Inetcore 


Ircomm 


Irdastk 


Pmerr 


Pmport 


Remnet 


Rnaapp 


Description 


Installable  device 
manager 


PCMCIA  client 
driver  module  for  the 
Socket 

Communications 
Dual  Serial  I/O 


Elink  Ethernet  driver 


Graphics,  Events,  and 

Windowing 

subsystem 


Components 


Windows  Internet 
DLL  core 


IrDA  communication 


IrDA  stack 


NDIS  network 
module 


PCL  printer  driver 


Printer  transport  layer 


Remote  networking 


Remote  networking 
application  support 


**  Note  ** 
Only  the  driver- 
related  components 
are  listed  here. 

Gcache,  gwectrl, 
gweshare,  gwesmain 
serdev 
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Serial 

Serial  Driver 

Softkb 

Soft  Input  Panel  (SIP) 
device  driver 

Sramdisk 

SRAM  (PCMCIA) 
card 

Tapi 

Telephony  API 

Tcpstk 

TCP/IP  stack 

Trueffs 

TrueFFS  block  device 
driver 

Unimodem 

TAPI  service 
provider  for  AT 
command  modems 

Usbd 

USB  module 

Usbmouse 

USB  mouse  driver 

Wininet 

Internet  API  support 

Winsock 

Winsock  services 

Xircce2 

Xircom  Ethernet 
driver 

Table  5.3  Driver  Modules  Table  [From:  GAR99] 


E.  WINDOWS  CE  I/O  SERVICES 

Windows  CE  provides  rich  support  for  several  communication  services.  A  few  of 

the  offered  services  are  ActiveSync,  Remnet,  and  Repllog.  Serial  and  IR 
communications  are  also  helpful  services  that  can  be  controlled  directly  through  the  use 
of  built-in  drivers. 
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1.  ActiveSync  Service 

ActiveSync  allows  the  user  to  synchronize  the  programs  and  data  contained  on  a 
Windows  CE  device  with  a  desktop  computer.  The  service  is  configurable,  but  the 
default  is  to  overwrite  the  identical  desktop  computer  files  with  those  contained  on  the 
CE  device.  ActiveSync  also  installs  new  applications  from  the  desktop  computer  onto 
the  CE  device.  In  its  previous  incarnation  with  Windows  CE  2.x,  ActiveSync  was  called 
“Windows  CE  Services”  and  provided  much  of  the  same  functionality.  ActiveSync  can 
store  a  backup  of  the  CE  device,  to  be  restored  later  in  the  event  of  a  catastrophe.  It  also 
provides  the  ability  to  view  and  transfer  files  from  the  desktop  PC  to  the  CE  device. 
From  a  vulnerability  standpoint,  ActiveSync  could  potentially  provide  a  channel  for 
captured  data  stored  in  a  file  to  be  exported  to  a  desktop  PC  whenever  the  user  synchs  the 
CE  device. 

2.  Remnet  Service 

Windows  CE  provides  a  connection  application  that  can  be  launched  from  the 
Control  Panel.  The  application  is  called  Remnet,  and  it  establishes  a  connection  from  the 
CE  device  to  a  host  computer.  This  application  cannot  be  used  at  the  same  time  as 
Repllog  (discussed  below).  Remnet  allows  applications  on  the  CE  device  to  use  a  direct 
serial  cable  connection  or  dial-up  networking  to  the  host  computer. 

3.  Repllog  Service 

Repllog  is  another  communication  service  that  is  used  in  conjunction  with 
ActiveSync.  It  cannot  be  used  concurrently  with  Remnet.  Repllog  provides  connectivity 
from  the  CE  device  to  the  host  computer,  and  also  monitors  the  connection  and  provides 
data  synchronization  services.  ActiveSync  executing  on  a  host  computer  can  detect 

Windows  CE  devices  running  Repllog,  but  it  can  not  detect  CE  devices  running  Remnet. 
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Repllog  is  a  service  offered  directly  by  the  Windows  CE  operating  system,  and  must  be 

included  at  build  time. 

4.  Serial  and  IR  Communications 

Several  serial  drivers  are  provided  with  Platform  Builder.  They  are:  the  native 
serial  driver,  Serial.dll;  the  16550  Serial  UART  driver,  Serl6550.1ib;  the  PC  card  serial 
driver,  Ser_card.lib;  and  the  dual  serial  driver,  Dualio.dll.  Caution  should  be  exercised 
when  using  serial  and  IR  ports,  because  the  information  transmitted  could  be  intercepted 
and  analyzed  by  a  malicious  application. 

F.  RECOMMENDATIONS 

Windows  CE  is  a  customizable,  general  purpose,  embedded  operating  system  that 
can  be  used  as  a  base  for  supporting  many  everyday  tasks.  A  PDA  operating  with 
Windows  CE  can  be  used  for  networking,  barcode  scanning,  maintaining  databases,  or 
the  playback  and  recording  of  sound  files.  However,  the  impact  of  security  on  the 
Windows  CE  operating  system  was  not  a  concern  during  its  original  design.  Speed  and 
system  performance  were  the  primary  concerns,  and  security  of  the  operating  system 
itself  was  not  a  high  priority  objective.  Future  work  could  include  analyzing  the 
Windows  CE  3.0  source  code  directly  for  dependencies  and  other  obstacles  to  system 
self-protection. 

The  utilization  of  Windows  CE  devices  in  government  or  military  environments 
requires  that  the  devices  offer  some  form  of  assurance.  The  devices  should  be  considered 
as  a  single  component  among  many  that  are  addressed  by  a  well-designed  security  policy. 
Due  to  the  system’s  flexibility  and  familiar  user  interface,  Windows  CE  devices  could 
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become  an  important  asset  in  such  tasks  as  inventory  control,  if  the  proper  security 
precautions  are  taken. 

It  is  recommended  that  a  streamlined  version  of  the  Windows  CE  OS  be  designed 
to  meet  the  customer's  specific  requirements.  The  system  should  be  optimized  for  the 
tasks  it  will  perform.  To  reduce  system  vulnerability,  unnecessary  components  of  the  OS 
should  be  removed.  For  example,  support  for  external  file  systems  could  be  removed, 
thereby  controlling  the  device's  ability  to  mount  external  volumes. 

If  there  are  no  plans  to  update  the  OS  remotely,  the  Dial-Up  Boot  Loader  (or 
DUB)  could  be  removed  from  the  OS  altogether.  If  it  is  used,  the  DUB  should  be 
configured  to  respond  in  a  safe,  non-compromising  manner  if  device  authentication  fails. 
The  default  behavior  upon  failure  is  to  halt  the  download  process  and  display  a  user 
message.  It  might  be  a  good  idea  to  record  the  DUB  actions  in  an  audit  log  on  the  server 
as  well. 

Support  for  infrared  (IR)  communication  provides  a  convenient  way  to  transfer 
programs  or  data  between  Windows  CE  devices.  However,  there  are  cases  in  which  data 
transfer  should  be  restricted,  and  removing  the  IR  support  from  the  OS  would  aid  in  that 
restriction.  Without  the  IR  support,  it  would  be  much  harder  for  rpgue  applications 
(either  malicious  or  non-approved)  to  spread  from  one  device  to  another.  This  would 
simplify  controlling  the  Windows  CE  device  configuration. 

The  Windows  CE  OS  should  be  built  using  protected  (non-kernel)  mode  only,  as 
this  affords  the  most  protection  of  the  system  memory.  Using  protected  mode  restricts 
the  physical  memory  access  of  user  level  threads.  This  decreases  the  possibility  that  a 

user  application  could  undermine  the  stability  of  the  kernel. 
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The  OEM  Certify  Module  functions  should  be  implemented  in  order  to  prevent 
unknown  modules  from  being  loaded,  restrict  access  to  the  system  APIs,  and  prevent 
write  access  to  certain  parts  of  the  system  registry.  As  currently  implemented,  the 
functions  provide  a  superficial  attempt  at  compliance,  rather  than  true  protection.  This 
means  that  all  driver  modules  should  not  be  .routinely  assigned  a  trust  level  of 
OEM_CERTIFY_TRUST.  Drivers  and  other  new  code  modules  would  have  to  be 
reviewed  by  an  outside  source  to  determine  their  trust  level.  After  approval,  the  drivers 
could  be  distributed  from  a  controlled  source.  Any  cryptography  used  in  the  Certify 
Module  functions  should  posses  an  adequate  key  length,  and  the  algorithms  themselves 
should  be  free  of  known  flaws.  Due  to  their  visibility  and  the  likelihood  of  attacks,  the 
Microsoft  Cryptographic  Service  Providers  might  not  be  the  best  choice  for 
implementing  cryptographic  algorithms.  In  certain  environments,  however,  it  is  possible 
that  the  CSPs  might  be  adequate  for  meeting  design  requirements. 

Each  PDA  should  be  assigned  a  unique,  immutable  device  ID  number.  A  data 
structure,  DEVICE_ID,  is  provided  for  storing  the  unique  device  ID.  Bounds  checking 
should  be  done  upon  the  return  of  a  DEVICEJD,  in  order  to  avoid  buffer  overflow 
problems.  The  device  ID  could  be  used  for  some  primitive  identification  and  auditing 
upon  synchronization  of  the  device  to  a  trusted  server.  The  decision  to  download  new 
applications  or  OS  updates  to  the  device  from  a  trusted  server  could  be  based  in  part  on 
the  device  ID.  However,  other  security  mechanisms  should  be  in  place,  so  that  the  device 
ID  is  not  the  only  criteria  relied  upon. 

When  a  CE  device  is  synchronized  with  a  desktop  computer,  it  uses  ActiveSync 
to  communicate  via  a  serial  port,  USB  port,  IR  port,  network  connection,  or  modem. 
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There  is  currently  no  identification  or  authentication  of  the  CE  device  or  the  computer  it 
connects  to.  Building  this  authentication  into  a  communications  protocol  is  an  area  for 
further  research.  It  might  also  be  possible  to  create  a  sort  of  VPN,  or  virtual  private 
network,  between  the  CE  device  and  the  desktop  to  prevent  the  disclosure  of  data  that  is 
sent  over  the  link.  Right  now,  PDA  devices  are  veiy  vulnerable  to  tools  such  as 
PortMon,  which  can  read  the  transmitted  data  directly.  PortMon  is  a  freeware  utility 
available  at  the  URL  www.svsintemals.com. 

Finally,  the  importance  of  the  human  element  in  computer  security  can  not  be 
overstated.  With  the  simplified  architecture  of  the  Windows  CE  OS,  anyone  who  has 
access  to  the  physical  device  has  access  to  all  of  the  information  stored  on  it.  The  CE 
device  should  never  be  left  unattended  or  given  to  someone  who  is  potentially 
untmst worthy.  A  mandatory  user  password  or  smartcard  system  should  be  used  to 
restrict  access  to  the  CE  device.  A  system  lock  feature  should  be  implemented  to 
suspend  the  device  after  a  defined  period  of  inactivity.  This  would  help  prevent  an 
unauthorized  person  from  using  the  device. 

Overall,  Windows  CE  devices  can  be  used  efficiently  for  performing  a  variety  of 
tasks.  They  provide  flexibility,  mobility,  and  a  familiar  user  interface.  Before  deploying 
CE  devices  in  organizations  where  security  is  a  concern,  some  modifications  to  the 
generic  CE  operating  system  should  be  made.  These  changes  might  include  removing 
capabilities  of  the  OS  that  are  not  needed,  building  the  kernel  in  protected  mode  only, 
implementing  the  Certify  Module  functions,  usage  of  a  unique  device  ID,  strengthening 
the  synchronization  protocols,  and  increasing  user  awareness  of  the  vital  importance  of 
good  security  practices. 
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APPENDIX  A  -  PLATFORM  BUILDER  AND  WINCE  TOOLS 

This  appendix  discusses  some  useful  software  and  hardware  tools  associated  with 
Windows  CE.  Platform  Builder  is  the  integrated  development  environment  for  building 
the  Windows  CE  operating  system.  The  CEPC  is  a  hardware  reference  platform  for 
downloading  and  testing  Windows  CE  operating  system  builds.  Embedded  Visual  Tools 
provides  support  for  building  C++  and  Visual  Basic  applications  for  Windows  CE. 

A.  MICROSOFT  WINDOWS  CE  PLATFORM  BUILDER  3.0 

Platform  Builder  (PB)  is  a  tool  for  building  custom  Windows  CE  operating 
systems  for  embedded  system  devices  [MICOOb].  The  eleven  CD-ROM  installation  kit 
includes  the  Windows  CE  3.0  operating  system,  a  set  of  embedded  development  tools,  an 
integrated  development  environment  (IDE),  support  for  the  Microsoft  run-time  libraries, 
the  ActiveSync  application,  and  sample  code.  An  Add-On  pack  containing  more 
debugger  tools,  a  limited  version  of  the  source  code,  and  Board  Support  Packages  (BSPs) 
for  various  processors  can  also  be  obtained  from  Microsoft. 

Nine  standard  configurations  of  the  Windows  CE  OS  can  be  built  using  PB 
[MICOOa].  The  configurations  are:  Minkem,  Mininput,  Mincomm,  Mingdi,  Minwmgr, 
Minshell,  Maxall,  IESample,  and  DUB.  Descriptions  of  these  OS  configurations  are 
listed  in  Table  A.l. 


Configuration 

Description 

Minkem 

a  minimal  version  of  Windows  CE 

Mininput 

provides  user  input  and  native  device  driver  support 

Mincomm 

includes  serial  communications  and  networking 

Mingdi 

includes  Graphics  Device  Interface  (GDI)  support 

Minwmgr 

provides  window  management 
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Minshell 

includes  almost  all  components,  provides  the  Task  Manager  and 
the  Command  Processor 

Maxall 

a  fully  configured  version  that  includes  several  communication 
applications 

IES  ample 

a  demonstration  version  that  includes  Microsoft  Internet 

Explorer  browser  components 

DUB 

includes  the  Dial-Up  Boot  Loader  for  downloading  and  updating 
the  OS 

Table  A.1  WINCE  OS  Configurations  [MICOOa] 


Ei  the  Windows  CE  penetration  testing  exercise,  the  Maxall  configuration  was 
used.  It  is  a  complete  version  of  the  CE  OS,  containing  all  non-conflicting  modules.  The 
following  table,  Table  A.2,  was  taken  from  the  Platform  Builder  online  help,  and  it  lists 
the  features  and  components  included  in  Maxall.  Similar  tables  exist  in  the  PB  online 
help  for  the  other  standard  OS  configurations. 


Functional  area 

Features 

Component/module 

names 

Kemel/OAL 

|Memory,  process 

Nk 

(Compression  support 

Nkcompr 

CoreDLL 

[Full  NLS-capable  APIs 

Coreloc 

(Local  heap  and  memory  allocation 

Lmem 

(Messaging,  user  input,  windowing,  and 

GDI  support 

Wmgr_c,  Mgdi_c 

Communications  support  for  serial 
(communications  and  TAPI 

Serdev,  Tapilib 

(Crypto  1.0  APIs  with  two  CSPs: 

|Rsabase.dll  and  Rsaenh.dll 

Cryptapi 

(WAV  API  support 

Waveapi 

(iMM  support 

Coreimm 

[Stdio  support 

Coresioa(w) 

[c  runtime  support 

Corestra(w) 

(Filelnfo  and  FileOpen  common  dialogs 

Fileinfo,  Fileopen 

[shell  API  support 

Shellapis 
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Soft  input  panel  support,  including  sample 
IM  (English/Korean/Japanese) 

Softkb,  Coresip 

FormatMessage  API  support  and  Message 
resources 

Fmtres  and  Fmtmsg 

Keyboard  accelerator  support 

Accel c 

TAPI  API  support 

Tapi,  Tapilib 

WAV  APIs 

Waveapi 

Crypto  APIs 

Cryptapi 

File  system 

RAM,  ROM  and  IFS  support 

Fsysram 

Database 

Fsdbase 

System  registry 

Fsreg 

Password  support 

Fspass 

FAT  file  system 

Fatfs 

Device  Manager 

Generic  device  driver  support 

Device 

GWES 

Messaging,  and  user  input  support 
including  support  for  standard  window 
controls,  such  as  buttons,  edit  controls, 
and  scroll  bars 

Msgbeep,  Msgbox, 
Msgque,  Uibase,  Edctl, 
Scbctl,  Btnctl,  Cascade, 
Clipbd 

Japanese  language  support,  including 
support  for  edit  controls,  IME,  and 
Japanese  characters 

Hwxjpn,  Msime98, 

Imejpp,  Edimejpn 

Korean  language  support,  including 
support  for  edit  controls,  IME,  and 

Korean  characters 

Edimefek,  Mshime97 

Timer  message  support 

Timer 

Clipboard  support 

Clipbd 

Power  management 

Getpower 

Notification  LED  support 

Nled 

GDI  support,  including  TrueType,  text 
drawing,  palette,  and  printing  support 

Mgtt,  Mgdrwtxt,  Mgpal, 
Mgprint 

Customizable  Touch  Screen  Calibration 
UI 

Tchui 

Network  UI  dialog  boxes 

Netui 

WAV  API  and  PCM  manager 

Waveapi 

IMM  support 

Immthunk 

Window  and  dialog  box  management 

Wmbase,  Dlgmgr 

Customizable  Startup,  Out  of  Memory, 
Touch  Screen  Calibration,  and 

Startui,  Oomui 
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Notification  UIs 


User  notifications  API  support 


Notify,  Notifymin 


Commctrl,  Cmbctl, 
Cascade,  Btnctl 


Windows  CE  common  controls  and 
common  dialog  boxes 


Basic  serial  communications  support 


Communications : 
Serial 


Serdev 


IR  Emulated  Serial  Port  support 


Serial  over  PC  Card 


IrComm 


Serial 


Communications: 

Networking 


Winsock  APIs 


Winsock 


Schannel  with  SGC  support,  and 
SCHNLUSA  (128-bit) 


Schannel,  SCHNLUSA 


TCP/IP  and  IR 


Tcpstk,  Lrdastk 


Network  Driver  Interface  Specification 
(NDIS) 


NDIS 


WNet/SMB  redirector 


Redir,  Netbios 


TAPI,  Unimodem 


Communications : 
Other 


Telephony  (TAPI) 


Customizable  Network  UI 


Netui 


IP  configuration  tool 


Ipconfig,  Route 


IP  Helper  APIs 


Iphlpapi 


Ntlmssp 


NTLM 


MSMQ 


Sample  network  drivers:  NDIS 


Management  SNMP  server 


SNMP  MIDs 


Device  drivers  ||Display 


PCMCIA  Card  and  socket  services 


Mqoa,  Msmqapi,  Msmqd, 
Msmqdm,  Msmqrt 


Ne2000,  Xircce2 


Snmp 


Snmp_mibii, 

Snmp_hostmib 


Display 


PCMCIA 


Keyboard  and  mouse 


Battery 


Notification  LED 


Touch  screen 


Kbdmsg.lib,  mouse 


Getpower 


Nled 


Tchui 
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USB  HID  driver 

Usbhid,  Usbmouse 

CardTest,  sample  PC  Card  driver 

NDIS  minidrivers 

Ne2000,  Xircce2 

ATA  disk 

Atadsik 

SRAM  disk 

Sramdisk 

Serial,  sample 

Serial.dll 

Audio 

Gsm610,  Audio 

COM/OLE 

COM,  OLE,  OLE  Automation,  Istorage  or 
full  DCOM/COM  support 

Com,  Olemain,  01eaut32, 
Docfile,  Mfs,  Nep 

DCOM 

Add-in 

technologies 

Handwriting  recognition  support 

Hwxusa 

Spelling  checker 

Splusa 

Microsoft  Message  Queue  Server 
(MSMQ) 

Mqoa,  Msmqapi,  Msmqd, 
Msmqdm,  Msmqrt 

Microsoft  Jscript®  development  software 

Jscript 

HTTP  Server 

Httpd,  Httpdadm, 

Httpdsvc 

Windows  CE  shell 
components 

Command  Processor 

Cmd 

Control  Panel  applications 

Commctrl 

Handheld  PC  style  shell 

Explorer,  Asform,  Ce 
shell 

Applications 

Communications 

Microsoft®  Pocket  Internet  Explorer 
Internet  browser 

Iexplore 

Microsoft®  Pocket  Word 

Pwd res,  Pword,  Pwwiff 

Inbox 

Labledit,  Mailutil, 
Msgstore 

Help  for  Windows  CE 

Peghelp 

Debugging 

Shell.exe  and  ToolHelp.dll 

Shell,  Toolhelp 

Table  A.2  Maxall  Components  [From:  Platform  Builder  Online  Help] 
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Environment  variables  may  be  set  to  control  the  driver  configurations.  Sample 
settings  are  contained  in  the  Cesysgen.bat  file.  For  more  information  on  the  environment 
variables,  see  the  online  Platform  Builder  help. 

1.  Installation 

In  order  to  install  and  use  Platform  Builder  on  a  desktop  PC,  local  administrator 
privileges  are  required.  It  is  important  to  use  the  same  administrator  account  when 
installing  and  using  Platform  Builder.  The  installation  is  accomplished  through  the  use  of 
wizards.  To  install,  the  user  must  insert  Platform  Builder  Disc  1  and  follow  the 
instructions  displayed  on  the  screen.  If  Ethernet  downloads  will  be  used,  that  choice 
should  be  selected  at  installation  time.  Note  that  selecting  parallel  port  downloads  will 
disable  local  parallel  port  printing.  So,  a  local  printer  can  not  be  used  if  the  parallel  port 
download  option  is  selected.  Also,  to  save  hard  disk  space,  the  unwanted  processors  can 
be  deselected  in  the  “CPU  Selection”  dialog  box.  To  build  images  for  the  CEPC,  only 
the  x86  microprocessor  support  is  needed.  Therefore,  all  other  processors  can  be 
deselected. 

2.  Hardware  Requirements 

The  Platform  Builder  installation  requires  an  x86  desktop  PC  running  Windows 
NT  or  Windows  2000  Professional,  with  Service  Pack  5  or  later.  The  recommended 
processor  is  one  that  is  equivalent  to  a  Pentium  200  MHz  or  higher.  Other  requirements 
are:  64  MB  RAM,  1.36  GB  of  hard-disk  space  available  for  a  typical  installation  or  7.8 
GB  for  the  complete  installation,  CD-ROM  or  DVD-ROM  drive,  VGA  or  higher 
resolution  monitor,  Microsoft  compatible  mouse,  bi-directional  parallel  port,  serial  port, 
Ethernet  network  card  (optional),  network  hub  (optional). 
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3.  Building  a  Platform 

The  best  way  to  build  a  platform,  or  Windows  CE  OS  image,  using  Platform 
Builder  is  to  follow  the  documented  procedure  in  the  Platform  Builder  online  help  or  the 
Getting  Started  Guide  [MICOOb].  There  are  four  main  steps  when  building  a  platform. 
Those  steps  are: 

1 .  configure  the  platform 

2.  make  the  OS  image  bin  file 

3.  transfer  the  platform  to  a  target  device  (such  as  a  CEPC) 

4.  debug  the  platform 

Platforms  may  be  built  with  kernel  debugging  either  enabled  or  disabled,  and 
release  or  debug  versions  of  the  platforms  can  be  built.  The  debug  versions  are  larger  in 
size,  so  care  should  be  taken  that  enough  RAM  exists  on  the  target  device  to  hold  the  OS 
image.  Kernel  profiling  can  also  be  built  into  the  platform  to  measure  the  system 
performance.  Refer  to  the  Platform  Builder  online  help  for  more  details.  Generally,  the 
documented  procedure  was  helpful,  and  no  major  problems  were  encountered  while 
building  platforms. 

B.  CEPC 

Platform  Builder  supports  the  CEPC,  which  is  an  x86  hardware  development 
platform.  In  many  situations,  the  CEPC  is  more  convenient  to  use,  since  it  is  easy  to 
download  new  OS  images  as  they  are  developed.  It  is  possible  to  assemble  a  CEPC  from 
basic  components.  The  necessary  hardware  is  listed  in  the  Getting  Started  Guide 
[MICOOb].  Very  minimal  information  is  provided  about  building  a  CEPC,  and  our 
attempts  in  that  area  were  not  successful.  An  easier  path  is  to  purchase  a  ready-made 
CEPC  from  a  third  party  vendor,  such  as  Special  Computing. 
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C.  MICROSOFT  EMBEDDED  VISUAL  TOOLS  3.0 


Microsoft  eMbedded  Visual  Tools  3.0  is  an  applications  development  suite  that 
allows  C++  and  Visual  Basic  programs  to  be  written  for  Windows  CE  devices.  It  is  very 
similar  to  Microsoft  Visual  Studio,  but  allows  the  development  of  Windows  CE 
applications  rather  than  Windows  NT,  98,  or  2000  programs.  Embedded  Visual  tools 
contains  an  editor,  debugger,  and  help  files,  all  within  a  convenient  graphical 
environment.  Embedded  Visual  Tools  can  be  ordered  at  no  cost  from  the  following  URL: 
http://www.microsoft.com/Windows/embedded/ce/tools/emvt30order.asp. 

D.  SUMMARY 

This  appendix  described  some  relevant  hardware  and  software  tools  that  are 
useful  for  the  development  and  testing  of  customized  versions  of  Windows  CE.  Platform 
Builder  and  CEPCs  are  excellent  tools  for  developing  a  customized  operating  system,  and 
applications  can  be  developed  using  Embedded  Visual  Tools. 
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APPENDIX  B  -  IMAGIX  4D  AND  SOFTWARE  ANALYSIS  TOOLS 


This  appendix  describes  various  software  analysis  tools.  The  tools  were 
investigated  in  order  to  find  the  most  suitable  application  for  analyzing  the  Windows  CE 
source  code.  One  important  criteria  for  tool  selection  was  the  ability  to  map  out 
dependencies  between  modules  in  the  source  code. 

A.  C  AND  C++  SOFTWARE  ANALYSIS  TOOLS  COMPARISON 

Several  reverse  engineering  and  software  analysis  tools  were  examined  for 
possible  use  in  analyzing  the  Windows  CE  3.0  source  code.  Imagix  4D  was  chosen  for 
its  ease  of  use  and  compatibility  with  the  Microsoft  Visual  Studio  compiler.  Table  B.l 
compares  the  tools  that  were  evaluated.  The  column  labeled  “Demo  Version”  indicates 
the  availability  of  a  demonstration  version  of  the  tool. 


Item 

Tool  Name 

OS 

Supported 

Cost 

Demo 

Version 

1 

CIAO/CIA 

Solaris,  SGI 

Free  for 
education 

use 

Yes 

PBS,  Software  Bookshelf 

Linux, 

Win32, 

Solaris 

Free 

Yes 

3 

Imagix  4D 

Win32,  Irix, 
Linux, 
Solaris, 
HP-UX 

Per 

installation, 
approx 
$2000  per 
computer 

Yes 

H 

+lReverseC 

Solaris 

Contact 

sales 

Yes 

5 

DMS  Software  Engineering  Toolkit 

Win32 

Contact 

sales 

No 

6 

j  Grasp 

Win32, 
Linux,  Java, 
and  more 

Free 

Yes 

Table  B .  1  Software  Analysis  Tools  Comparison 
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B.  DESCRIPTION  OF  SOFTWARE  TOOLS 


The  following  is  a  brief  description  of  the  software  analysis  tools,  and  a  listing  of 
where  the  tools  can  be  obtained. 

1.  CIAO/CIA 

CIAO  /  CIA  is  a  reverse  engineering  tool  with  a  graphical  user  interface.  It 
allows  the  user  to  query  and  browse  structural  connections  in  software  and  document 
repositories.  It  can  be  found  at  the  URL  http://www.research.att.com/~ciao/. 

2.  PBS 

This  tool  is  web  based,  and  operates  within  a  web  browser.  The  user  can  navigate 
information  representing  large  software  systems.  The  tool  shows  the  relationships 
between  files,  but  it  is  uncertain  whether  it  can  permit  viewing  at  the  function  call  level. 
It  can  be  found  at  the  URL  swag.uwaterloo.ca/pbs/. 

3.  Imagix  4D 

This  tool  can  be  used  to  reverse-engineer  large,  complex,  or  unfamiliar  software 
written  in  C/C++.  It  has  a  graphical  color  3D  view  of  dependencies,  supports  the 
creation  and  printing  of  reports,  and  allows  integrated  text  editing  of  the  source  code.  It 
can  support  the  parsing  of  several  compiler  types  through  customized  compiler 
configuration  files.  Information  about  this  tool  can  be  found  at  the  URL 
www.imagix.com. 

4.  +lReverseC 

This  tool  parses  C  code,  and  graphically  displays  the  calling  structure.  It  can  be 
found  at  the  URL  www.plus-one.com/+lReverseC  fact  she.et.html. 
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5.  DMS  Software  Engineering  Toolkit 

This  toolkit  provides  a  set  of  tools  for  carrying  out  custom  re-engineering  of 
medium  and  large-scale  software  systems.  It  supports  analysis,  porting,  translation, 
interface  changes,  and/or  domain-specific  program  generation.  This  tool  had  no  demo 
and  their  website  was  rather  confusing.  The  toolkit  can  be  found  at  the  URL 
www.semdesigns.com. 

6.  jGrasp 

jGrasp  makes  extensive  use  of  Control  Structure  Diagrams.  The 
Control  Structure  Diagram  (CSD)  is  a  control  flow  and  data  structure  diagram  that  is 
designed  to  fit  into  the  space  that  is  normally  taken  by  indentation  in  source  code.  The 
intention  of  the  CSD  is  to  improve  the  comprehension  efficiency  of  source  code  and,  as  a 
result,  improve  software  reliability  and  reduce  software  costs.  The  purpose  of  GRASP  is 
to  provide  this  diagram  in  the  context  of  a  full-featured  development  environment.  At  this 
point  it  would  be  called  a  "light"  IDE,  as  there  are  no  integrated  debuggers  or  navigation 
and  related  features.  This  tool  is  free,  easy  to  use,  and  provides  a  good  sense  of  the 
source  code  complexity.  A  complexity  profile  graph  is  a  visualization  of  the  complexity 
of  a  program  unit,  based  upon  a  profile  metric  designed  to  compute  complexity  at  various 
levels  of  granularity.  Unfortunately,  jGrasp  does  not  generate  complexity  profile  graphs 
for  C  and  C++,  but  only  for  Java  and  Ada  at  this  time.  The  tool  can  be  found  at  the  URL 
http://www.eng.aubum.edu/department/cse/research/grasp/. 

After  investigating  these  six  software  analysis  tools,  Imagix  4D  was  selected  to 
aid  in  the  analysis  of  the  Windows  CE  3.0  source  code.  Imagix  is  capable  of  analyzing 
very  large  software  projects,  and  was  developed  specifically  for  reverse  engineering 


91 


legacy  code.  It  has  very  good  support  for  the  Microsoft  Visual  C++  compiler,  which  is 
probably  the  most  similar  to  the  compiler  used  on  the  Windows  CE  source  code.  Imagix 
4D  also  has  a  very  understandable  graphical  user  interface,  and  is  comparatively  easy  to 
use.  The  selling  point  of  this  tool  was  its  graphical  representation  of  dependencies  at  the 
file,  module,  and  function  levels.  This  is  exactly  the  functionality  that  was  needed  to 
examine  the  relationships  between  modules  in  the  Windows  CE  3.0  source  code. 
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